8 ms·

Git 2.13

240 points by edmorley 9y ago

ryanar 9y ago
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 9y ago
  Not uncommon! This is why .gitignore is the first thing I explain to git newcomers.
  - matt_kantor 9y ago
    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 9y ago
      Yeah I totally misread that... Nevertheless, .gitignore should still be the first thing you learn about git :)
- simias 9y ago
  Indeed. My current workaround was simply not to put any email in ~/.gitconfig. Upon commiting for the first time in a new repo git would complain, then I could set the correct email for this particular repo using `git config user.email $email`.
  - dmit 9y ago
    I think this only works if you set `git config --global user.useconfigonly true`, otherwise git will try to guess your name/email.
    - simias 9y ago
      It does, thank you for that tip! So far I'd just `git commit --amend --reset-author` after setting the email the first time.
freditup 9y ago
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!
- peff 9y ago
  Yes, you're right. The `push` command was added because of backwards compatibility issues with `save` (and essentially replaces it).
  - masklinn 9y ago
    What are the improvements of push over save? Does it allow incrementing a stash?
    - peff 9y ago
      It's essentially the same except for the arguments. `save` took the whole command-line to be the stash message, which was confusingly unlike the rest of Git (and needed to be addressed before pathspec support could be added).
      - manojlds 9y ago
        Was confused with the docs. Now it makes sense, the difference between save and push.
- bruce_one 9y ago
  Ooh, this might mean some vim-fugitive beauty is on the horizon :-) The vim-fugitive Gdiff is a really nice interface (imo) and a stash equivalent would be amazing :-)
  - 9y ago
styfle 9y ago
> 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.
- MBlume 9y ago
  Pretty sure this already existed with different syntax. Under those circumstances I'd probably use git svn, I always found git svn to be a better svn client than svn.
  - styfle 9y ago
    Does git svn build a local git repo out of the svn server or just act as a normal svn client?
- avar 9y ago
  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/ac3f5a346860b824e083c5d305757c3260565475 https://github.com/git/git/commit/ac3f5a346860b824e083c5d305...
clumsysmurf 9y ago
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/?source=navbar https://sourceforge.net/projects/git-osx-installer/files/?so... 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 9y ago
  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 9y ago
    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.
    - cjlm 9y ago
      Why is it a travesty?
      - stephenr 9y ago
        It has fundamental flaws in how it handles dependencies, particularly when dealing with binary packages. installing user-owned global software is a terrible idea. The maintainers of homebrew are aware of both issues and simply don't care: they are not going to fix either, because they won't even acknowledge that they're actual problems.
        lgas 9y ago
        Possibly because many people use their software and are very happy with it without running into those issues and addressing them would be a tremendous amount of work.
0x0 9y ago
The "includeIf" thing based on filesystem paths for setting the user.email gitconfig seems useful!
ReligiousFlames 9y ago
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 9y ago
  Isn't signing a hash the standard procedure for signatures?
  - dozzie 9y ago
    The thing is, you are signing hash of a hash of data instead of simply hash of data.
- lgas 9y ago
  What would be the benefit of signing content instead of hashes?
  - rurban 9y ago
    The benefit would be to trust the content, and not the hash of the content. Esp. with SHA1 being the only hash so far.
brutopia 9y ago
Not related to this but please github choose a better font to render code in android browsers, the current one's unreadable!
- Kiro 9y ago
  Looks fine to me. What version are you on?
  - brutopia 9y ago
    Chrome 58 on android 6.0.1 and the device is nexus 7 2013
    - pawadu 9y ago
      Borrowed someones nexus [praise Duarte?] to check this... Text looks good, code snippets looks kinda crap. Not unreadable but not great either. Same page looks great on firefox so this is chrome shenanigans.
- charlieegan3 9y ago
  I thought GitHub used system fonts? https://news.ycombinator.com/item?id=12075623 https://news.ycombinator.com/item?id=12075623
  - marcoms 9y ago
    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
- kingosticks 9y ago
  Is this the problem where it appears almost double spaced? That's what I get on Chrome 58.0.3029.83. And the scrolling performance is horrible, I assume it's some js stuff happening.
jwilk 9y ago
Release notes: https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/RelNotes/2.13.0.txt https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio...
nailer 9y ago
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.
- speps 9y ago
  The GitHub page seems to have `MinGit` releases : https://github.com/git-for-windows/git/releases/latest https://github.com/git-for-windows/git/releases/latest
  - nailer 9y ago
    MinGit-2.13.0-64-bit.zip\usr\bin still includes an entire copy of openssh and much more besides.
- tetromino_ 9y ago
  > 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 9y ago
    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_ 9y ago
      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.

240 points by edmorley 9y ago

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 9y ago
Not uncommon! This is why .gitignore is the first thing I explain to git newcomers.
- matt_kantor 9y ago
  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 9y ago
    Yeah I totally misread that... Nevertheless, .gitignore should still be the first thing you learn about git :)
simias 9y ago
Indeed. My current workaround was simply not to put any email in ~/.gitconfig. Upon commiting for the first time in a new repo git would complain, then I could set the correct email for this particular repo using `git config user.email $email`.
- dmit 9y ago
  I think this only works if you set `git config --global user.useconfigonly true`, otherwise git will try to guess your name/email.
  - simias 9y ago
    It does, thank you for that tip! So far I'd just `git commit --amend --reset-author` after setting the email the first time.

freditup 9y ago

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!

peff 9y ago
Yes, you're right. The `push` command was added because of backwards compatibility issues with `save` (and essentially replaces it).
- masklinn 9y ago
  What are the improvements of push over save? Does it allow incrementing a stash?
  - peff 9y ago
    It's essentially the same except for the arguments. `save` took the whole command-line to be the stash message, which was confusingly unlike the rest of Git (and needed to be addressed before pathspec support could be added).
    - manojlds 9y ago
      Was confused with the docs. Now it makes sense, the difference between save and push.
bruce_one 9y ago
Ooh, this might mean some vim-fugitive beauty is on the horizon :-) The vim-fugitive Gdiff is a really nice interface (imo) and a stash equivalent would be amazing :-)
- 9y ago

styfle 9y ago

> 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.

MBlume 9y ago
Pretty sure this already existed with different syntax. Under those circumstances I'd probably use git svn, I always found git svn to be a better svn client than svn.
- styfle 9y ago
  Does git svn build a local git repo out of the svn server or just act as a normal svn client?
avar 9y ago
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/ac3f5a346860b824e083c5d305757c3260565475 https://github.com/git/git/commit/ac3f5a346860b824e083c5d305...

clumsysmurf 9y ago

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/?source=navbar https://sourceforge.net/projects/git-osx-installer/files/?so... 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 9y ago
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 9y ago
  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.
  - cjlm 9y ago
    Why is it a travesty?
    - stephenr 9y ago
      It has fundamental flaws in how it handles dependencies, particularly when dealing with binary packages. installing user-owned global software is a terrible idea. The maintainers of homebrew are aware of both issues and simply don't care: they are not going to fix either, because they won't even acknowledge that they're actual problems.
      - lgas 9y ago
        Possibly because many people use their software and are very happy with it without running into those issues and addressing them would be a tremendous amount of work.

0x0 9y ago

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

ReligiousFlames 9y ago

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 9y ago
Isn't signing a hash the standard procedure for signatures?
- dozzie 9y ago
  The thing is, you are signing hash of a hash of data instead of simply hash of data.
lgas 9y ago
What would be the benefit of signing content instead of hashes?
- rurban 9y ago
  The benefit would be to trust the content, and not the hash of the content. Esp. with SHA1 being the only hash so far.

brutopia 9y ago

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

Kiro 9y ago
Looks fine to me. What version are you on?
- brutopia 9y ago
  Chrome 58 on android 6.0.1 and the device is nexus 7 2013
  - pawadu 9y ago
    Borrowed someones nexus [praise Duarte?] to check this... Text looks good, code snippets looks kinda crap. Not unreadable but not great either. Same page looks great on firefox so this is chrome shenanigans.
charlieegan3 9y ago
I thought GitHub used system fonts? https://news.ycombinator.com/item?id=12075623 https://news.ycombinator.com/item?id=12075623
- marcoms 9y ago
  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
kingosticks 9y ago
Is this the problem where it appears almost double spaced? That's what I get on Chrome 58.0.3029.83. And the scrolling performance is horrible, I assume it's some js stuff happening.

jwilk 9y ago

Release notes: https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/RelNotes/2.13.0.txt https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio...

nailer 9y ago

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.

speps 9y ago
The GitHub page seems to have `MinGit` releases : https://github.com/git-for-windows/git/releases/latest https://github.com/git-for-windows/git/releases/latest
- nailer 9y ago
  MinGit-2.13.0-64-bit.zip\usr\bin still includes an entire copy of openssh and much more besides.
tetromino_ 9y ago
> 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 9y ago
  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_ 9y ago
    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.