
Git 2.13 - edmorley
https://github.com/blog/2360-git-2-13-has-been-released
======
freditup
Hidden in the notes at the bottom is a pretty useful improvement to 'git
stash':

> 'git stash save' now accepts pathspecs. You can use this to create a stash
> of part of your working tree, which is handy when picking apart changes to
> turn into clean commits.

I believe there may be a slight error in the GitHub blog post I quoted above:
from what I can tell, it's actually the 'git stash push' command that now
accepts pathspecs. But either way, still a neat new feature!

~~~
eslaught
It's worth noting that "git stash -p" (aka "git stash --patch") already exists
and allows you to commit individual files or hunks within a file. Though the
cost is going through an interactive interface, so some users might prefer the
new "git stash push". Still, if you can't upgrade, use "git stash -p".

~~~
colept
Patch and interactive modes are the best thing next to sliced bread. I'll
start with a feature and end up refactoring something and it's difficult to
organize large sets of changes without them.

~~~
ooqr
They're definitely prereqs to upper-level git wizardry

------
ryanar
Oh I am really digging the change to allow directory level configs for config
settings.

I have commited with my work credentials to open source projects more times
than I can count

~~~
pawadu
Not uncommon! This is why .gitignore is the first thing I explain to git
newcomers.

~~~
matt_kantor
I think you misread the parent comment. They didn't say "committed my work
credentials", it was "committed _with_ my work credentials". As in they have
two different identities and used the wrong one when committing a change, so
the commit author was incorrect.

Being able to set configs per directory provides a workaround.

~~~
pawadu
Yeah I totally misread that...

Nevertheless, .gitignore should still be the first thing you learn about git
:)

------
styfle
> git branch, git tag, and git for-each-ref all learned the --no-contains
> option to match their existing --contains option. This can let you ask which
> tags or branches don't have a particular bug (or bugfix).

I'm surprised that didn't exist already. Several years ago, I worked on a tool
to scan SVN merge history and save in a graph database so one could ask this
type of question, "Does this branch contain the fix?". Or the opposite, "Which
branches do not contain this fix?".

It was a mess because there were 8 million commits in the repo and clients
ranged from SVN 1.4 to SVN 1.8 (the server was upgraded too).

It would have made more sense to use git for something like that but it's hard
to get thousands of devs to switch.

~~~
avar
I implemented that feature in the 2.13 release, glad to see interest in it,
more details on how it works & can be used from the commit message[1]:

This allows for finding the last-good rollout tag given a known-bad <commit>.
Given a hypothetically bad commit cf5c725, the git version to revert to can be
found with this hacky two-liner:

    
    
        (git tag -l 'v[0-9]*'; git tag -l --contains cf5c725 'v[0-9]*') |
            sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10
    

With this new --no-contains option the same can be achieved with:

    
    
        git tag -l --no-contains cf5c725 'v[0-9]*' | sort | tail -n 10
    

As the filtering machinery is shared between the tag, branch & for-each-ref
commands, implement this for those commands too. A practical use for this with
"branch" is e.g. finding branches which were branched off between v2.8.0 and
v2.10.0:

    
    
        git branch --contains v2.8.0 --no-contains v2.10.0
    

1\.
[https://github.com/git/git/commit/ac3f5a346860b824e083c5d305...](https://github.com/git/git/commit/ac3f5a346860b824e083c5d305757c3260565475)

~~~
styfle
Very cool! Thanks for the examples and linking back to the commit :+1:

------
clumsysmurf
Anyone know what has happened to the OSX builds? The de-facto project 'git-
osx-installer' doesn't have binaries after 2.10

[https://sourceforge.net/projects/git-osx-
installer/files/?so...](https://sourceforge.net/projects/git-osx-
installer/files/?source=navbar)

git-scm.com says:

"You are downloading version 2.10.1 of Git for the Mac platform. This is the
most recent maintained build for this platform. It was released 7 months ago,
on 2016-10-14."

[https://git-scm.com/download/mac](https://git-scm.com/download/mac)

~~~
sillysaurus3
Probably homebrew. `brew install git --HEAD` gives v2.12.0, and I'm apparently
using v2.11.0. It installs bash and zsh completions too, which are nice.

~~~
stephenr
Not everyone wants to use that travesty of a "package manager".

The person you replied to was asking specifically about the native macos
packages linked from the git official website.

~~~
sillysaurus3
I only meant that Homebrew is so popular that I wouldn't be surprised if it
was the reason why the OS X builds on the official website fell into
disrepair.

~~~
stephenr
I see. Thats frankly a poor state of affairs if it's the case.

The linked builds from git-scm.com are built by
[https://github.com/timcharper/git_osx_installer](https://github.com/timcharper/git_osx_installer)
(but hosted on sourceforge for some bizarre reason), however that repo seems a
little inactive lately, bar issues from users.

Another thing to love about Mercurial: the project handles packaging, rather
than relying on third parties to do their job for them:
[https://www.mercurial-scm.org/downloads](https://www.mercurial-
scm.org/downloads)

------
0x0
The "includeIf" thing based on filesystem paths for setting the user.email
gitconfig seems useful!

------
ReligiousFlames
On git moving away from SHA1: it's about time.

\- There shouldn't be too many nor too few hash algos. Too many: paradox of
choice, user confusion and interop overhead. Too few: security monoculture
risks being broken by well-funded state actors

\- Sane, future-ready default: SHA3-512

Also, git GPG signing should change to signing content, in addition to or
instead of, hashes.

~~~
adrianN
Isn't signing a hash the standard procedure for signatures?

~~~
dozzie
The thing is, you are signing hash of a hash of data instead of simply hash of
data.

------
jwilk
Release notes:

[https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio...](https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/RelNotes/2.13.0.txt)

------
nailer
Anyone know where to get _clean_ git builds for Windows without any extra crap
like the "git for Windows" builds have?

\- Windows comes with bash

\- Microsoft have an excellent openssh implementation on their github

\- I don't want some dude's cool $PS1 and shortcuts and icons.

I just want git.

~~~
tetromino_
> Windows comes with bash

That's an extremely charitable way of phrasing it. 64-bit Windows 10 in
developer mode has bash as an optionally installable component. AFAIK, bash is
not installed by default and it's unavailable on 32-bit or in older Windows
versions.

If you want to allow a wide range of users, including those with corporate- or
government-IT issued machines, to run your build, you need to support older
Windows versions down to at least 7. Which means that you cannot assume native
bash.

~~~
nailer
Nobody is discussing assuming anything. It's simply preferable to have
optional components for legacy systems than to add a second copy of bash and
ssh to every machine.

~~~
tetromino_
It is certainly preferable to you and others in a similar situation. It is, I
suspect, somewhat less preferable to git maintainers, who would need to build
and test an additional binary package using a different toolchain for every
release, and deal with bug reports from confused users mixing up git-with-bash
and git-without-bash.

------
brutopia
Not related to this but please github choose a better font to render code in
android browsers, the current one's unreadable!

~~~
charlieegan3
I thought GitHub used system fonts?

[https://news.ycombinator.com/item?id=12075623](https://news.ycombinator.com/item?id=12075623)

~~~
marcoms
They try, but there is not really predictable and simple way to select those
fonts in CSS. I've had times when Courier was used on Linux because the MS
fonts we installed.

I would prefer they just do font-family: monospace

