6 ms·

Git 1.9 Release Notes

104 points by rjzzleep 13y ago

tekacs 13y ago
The linked page was incredibly painful to read (and arbitrarily chosen and variable width and downright ugly?) Might want to try this instead: https://github.com/git/git/blob/master/Documentation/RelNotes/1.9.0.txt https://github.com/git/git/blob/master/Documentation/RelNote...
- deleted 13y ago
  [deleted]
- antirez 13y ago
  Bonus point of the linked page, the banner on the top detects you are on a mobile phone and spams you with an alert().
  - tekacs 13y ago
    Neither link here did this for me in Chrome for iOS. Odd?
- deleted 13y ago
  [deleted]
- roryokane 13y ago
  The official Git site http://git-scm.com/ http://git-scm.com/ links to this for the release notes: https://raw.github.com/git/git/master/Documentation/RelNotes/1.9.0.txt https://raw.github.com/git/git/master/Documentation/RelNotes.... I think that’s even more readable.
- kaichanvong 13y ago
  None of these were to my liking. I copy and pasted and viewed in Marked then saved and shared with you guys: http://kaivong.com/my_cloud/Git-v1.9.0-Release-Notes.html http://kaivong.com/my_cloud/Git-v1.9.0-Release-Notes.html Feel free to mirror or tell me of a nicer version!
baby 13y ago
Still no easy way to use emacs as a diff tool.
- daenney 13y ago
  Perhaps emacs is to blame for that.
- davvid 13y ago
  Do you mean `git difftool --tool=emerge`, or are you thinking of something else?
- edhebert 13y ago
  vc-diff works pretty well.
- fafner 13y ago
  smerge-mode or use the emerge diff tool setting
spindritf 13y ago
Already packaged if you're using Ubuntu https://launchpad.net/~git-core/+archive/ppa https://launchpad.net/~git-core/+archive/ppa # git --version git version 1.9.0
- hk__2 13y ago
  You can install it on OSX with Homebrew: brew install https://raw.github.com/asaph/homebrew/2897329686d905fc357c5e2e87597c8f6a8e9cd1/Library/Formula/git.rb But they want to wait a few days to ensure there’re no bugs found [1] before adding it to the main repo. [1]: https://github.com/Homebrew/homebrew/pull/26734 https://github.com/Homebrew/homebrew/pull/26734
- dfc 13y ago
  The release candidates have been in Debian/sid for a week or two now. I have not noticed any problems. It looks like the only differences between rc3 and the stable release are some documentation changes. If you are feeling adventurous 2.0 is in experimental: root@ronin:~# apt-show-versions -a git git:amd64 1:1.9.0~rc3-1 install ok installed git:amd64 1:1.9.0~rc3-1 unstable ftp.us.debian.org git:amd64 1:2.0~next.20140207-1 experimental ftp.us.debian.org git:amd64/unstable 1:1.9.0~rc3-1 uptodate
- pritambaral 13y ago
  Arch repo got it too.
rmcpherson 13y ago
I don't see any significant performance improvements listed in the release notes. Git's memory-intensive handling of large files with most operations continues to make it difficult to use as a versioned, incremental backup tool. Although I know that backup is not Git's originally intended purpose, it is otherwise a very good solution. Moreover, companies with large repositories run up against these limitations as well (see Facebook's move from git to mercurial). Does anyone know whether any improvements in these areas are slated for git 2.0 or being considered for a later point release? They could even draw on the increasingly-great bup tool (https://github.com/bup/bup https://github.com/bup/bup) that uses the git pack-file format with a rolling checksum algorithm to do fast deduplication within files.
- rjzzleep 13y ago
  facebooks solution allows you to work better with shallow copies. it doesn't magically solve the size issue. it's much faster, because it doesn't do the real work. [1] also I distinctly remember that the linux kernel, rewinds history every so often(but maybe my memory is just playing tricks on me). git is not a backup tool, i always scold people for checking large binary files into their text file revision systems. take a look at ori[2] for git like backup solution. git annex is also an interesting solution[3]. although he says specifically to not confuse it for a dropbox clone. now to get back to your first point. as we established facebooks speedup happens because of difference in dealing with shallow cloned repositories. it seems to me like git is making improvements in that regard see the following: > * Fetching from a shallowly-cloned repository used to be forbidden, primarily because the codepaths involved were not carefully vetted and we did not bother supporting such usage. This release attempts to allow object transfer out of a shallowly-cloned repository in a more controlled way (i.e. the receiver become a shallow repository with a truncated history). [1] https://bitbucket.org/facebook/remotefilelog https://bitbucket.org/facebook/remotefilelog [2] http://ori.scs.stanford.edu/ http://ori.scs.stanford.edu/ [3] http://git-annex.branchable.com/ http://git-annex.branchable.com/ EDIT: bup looks nice though, thanks for the info
  - rmcpherson 13y ago
    I missed that about fetching from shallow cloning. Thanks for pointing that out. I'll have to check out ori as well.
corndoge 13y ago
I don't understand why, when a major software package gets even the slightest version increment, it has to top HN. Git's number is bigger? Big deal. If there was a monumental change to Git contained in those release notes, then maybe. But a few changes involving whitespace and colons are hardly 'deeply interesting'.
- sho_hn 13y ago
  Except you can't know that the changes are minor without looking at the release notes. Between that and the fact that even minor changes multiply in importance across the large number of git users, it's apparently interesting enough.
  - Pacabel 13y ago
    Version numbers are supposed to indicate information like that, at a high level. Under a sensible version numbering scheme, an x.0 release will have important changes, while an x.9 release very likely shouldn't.
    - deleted 13y ago
      [deleted]
    - jbnicolai 13y ago
      Not really, an increment to the major version number simply indicates non backwards-compatible API changes. See: http://semver.org/ http://semver.org/
- username223 13y ago
  It's the usual minor version release spam. Not even worth figuring out whether it's blog-spam, karma whoring, or (unlikely) genuine news.
gnoway 13y ago
I appreciate the change to --tags.
deleted 13y ago
[deleted]
mariusmg 13y ago
Now let's see how fast msysgit gets updated on Windows.
- Flenser 13y ago
  https://code.google.com/p/msysgit/downloads/list?q=full+1.9 https://code.google.com/p/msysgit/downloads/list?q=full+1.9
herge 13y ago
This is older than git 1.9, but git supports mercurial repositories[1]. I used to have to use mercurial to deal with kiln (which couldn't convert our repo to git), but now I happily work with git and everything is 10 times faster. [1]: https://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/ https://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2...
- akxak 13y ago
  When was the last time you used Mercurial? Git being 10 times faster seems dated. Especially if you're using Facebook's fabulous Mercurial extensions, which actually make Mercurial faster than Git. https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
  - stuhood 13y ago
    There are no version numbers in those benchmarks, nor any way to reproduce them. So take them with a few grains of salt. In particular, how old was the version of git they were testing with? Were they using SSDs?
- barbs 13y ago
  I'm curious: where does this 10x speed increase come from? are you implying that git is inherently faster than mercurial? I've not actually used mercurial myself so I wouldn't know...
  - herge 13y ago
    git status is 10 times faster on my machine for the same repository than hg status.

104 points by rjzzleep 13y ago

The linked page was incredibly painful to read (and arbitrarily chosen and variable width and downright ugly?) Might want to try this instead: https://github.com/git/git/blob/master/Documentation/RelNotes/1.9.0.txt https://github.com/git/git/blob/master/Documentation/RelNote...

deleted 13y ago
[deleted]
antirez 13y ago
Bonus point of the linked page, the banner on the top detects you are on a mobile phone and spams you with an alert().
- tekacs 13y ago
  Neither link here did this for me in Chrome for iOS. Odd?
deleted 13y ago
[deleted]
roryokane 13y ago
The official Git site http://git-scm.com/ http://git-scm.com/ links to this for the release notes: https://raw.github.com/git/git/master/Documentation/RelNotes/1.9.0.txt https://raw.github.com/git/git/master/Documentation/RelNotes.... I think that’s even more readable.
kaichanvong 13y ago
None of these were to my liking. I copy and pasted and viewed in Marked then saved and shared with you guys: http://kaivong.com/my_cloud/Git-v1.9.0-Release-Notes.html http://kaivong.com/my_cloud/Git-v1.9.0-Release-Notes.html Feel free to mirror or tell me of a nicer version!

baby 13y ago

Still no easy way to use emacs as a diff tool.

daenney 13y ago
Perhaps emacs is to blame for that.
davvid 13y ago
Do you mean `git difftool --tool=emerge`, or are you thinking of something else?
edhebert 13y ago
vc-diff works pretty well.
fafner 13y ago
smerge-mode or use the emerge diff tool setting

spindritf 13y ago

Already packaged if you're using Ubuntu https://launchpad.net/~git-core/+archive/ppa https://launchpad.net/~git-core/+archive/ppa # git --version git version 1.9.0

hk__2 13y ago
You can install it on OSX with Homebrew: brew install https://raw.github.com/asaph/homebrew/2897329686d905fc357c5e2e87597c8f6a8e9cd1/Library/Formula/git.rb But they want to wait a few days to ensure there’re no bugs found [1] before adding it to the main repo. [1]: https://github.com/Homebrew/homebrew/pull/26734 https://github.com/Homebrew/homebrew/pull/26734
dfc 13y ago
The release candidates have been in Debian/sid for a week or two now. I have not noticed any problems. It looks like the only differences between rc3 and the stable release are some documentation changes. If you are feeling adventurous 2.0 is in experimental: root@ronin:~# apt-show-versions -a git git:amd64 1:1.9.0~rc3-1 install ok installed git:amd64 1:1.9.0~rc3-1 unstable ftp.us.debian.org git:amd64 1:2.0~next.20140207-1 experimental ftp.us.debian.org git:amd64/unstable 1:1.9.0~rc3-1 uptodate
pritambaral 13y ago
Arch repo got it too.

rmcpherson 13y ago

I don't see any significant performance improvements listed in the release notes. Git's memory-intensive handling of large files with most operations continues to make it difficult to use as a versioned, incremental backup tool. Although I know that backup is not Git's originally intended purpose, it is otherwise a very good solution. Moreover, companies with large repositories run up against these limitations as well (see Facebook's move from git to mercurial). Does anyone know whether any improvements in these areas are slated for git 2.0 or being considered for a later point release? They could even draw on the increasingly-great bup tool (https://github.com/bup/bup https://github.com/bup/bup) that uses the git pack-file format with a rolling checksum algorithm to do fast deduplication within files.

rjzzleep 13y ago
facebooks solution allows you to work better with shallow copies. it doesn't magically solve the size issue. it's much faster, because it doesn't do the real work. [1] also I distinctly remember that the linux kernel, rewinds history every so often(but maybe my memory is just playing tricks on me). git is not a backup tool, i always scold people for checking large binary files into their text file revision systems. take a look at ori[2] for git like backup solution. git annex is also an interesting solution[3]. although he says specifically to not confuse it for a dropbox clone. now to get back to your first point. as we established facebooks speedup happens because of difference in dealing with shallow cloned repositories. it seems to me like git is making improvements in that regard see the following: > * Fetching from a shallowly-cloned repository used to be forbidden, primarily because the codepaths involved were not carefully vetted and we did not bother supporting such usage. This release attempts to allow object transfer out of a shallowly-cloned repository in a more controlled way (i.e. the receiver become a shallow repository with a truncated history). [1] https://bitbucket.org/facebook/remotefilelog https://bitbucket.org/facebook/remotefilelog [2] http://ori.scs.stanford.edu/ http://ori.scs.stanford.edu/ [3] http://git-annex.branchable.com/ http://git-annex.branchable.com/ EDIT: bup looks nice though, thanks for the info
- rmcpherson 13y ago
  I missed that about fetching from shallow cloning. Thanks for pointing that out. I'll have to check out ori as well.

corndoge 13y ago

I don't understand why, when a major software package gets even the slightest version increment, it has to top HN. Git's number is bigger? Big deal. If there was a monumental change to Git contained in those release notes, then maybe. But a few changes involving whitespace and colons are hardly 'deeply interesting'.

sho_hn 13y ago
Except you can't know that the changes are minor without looking at the release notes. Between that and the fact that even minor changes multiply in importance across the large number of git users, it's apparently interesting enough.
- Pacabel 13y ago
  Version numbers are supposed to indicate information like that, at a high level. Under a sensible version numbering scheme, an x.0 release will have important changes, while an x.9 release very likely shouldn't.
  - deleted 13y ago
    [deleted]
  - jbnicolai 13y ago
    Not really, an increment to the major version number simply indicates non backwards-compatible API changes. See: http://semver.org/ http://semver.org/
username223 13y ago
It's the usual minor version release spam. Not even worth figuring out whether it's blog-spam, karma whoring, or (unlikely) genuine news.

gnoway 13y ago

I appreciate the change to --tags.

deleted 13y ago

[deleted]

mariusmg 13y ago

Now let's see how fast msysgit gets updated on Windows.

Flenser 13y ago
https://code.google.com/p/msysgit/downloads/list?q=full+1.9 https://code.google.com/p/msysgit/downloads/list?q=full+1.9

herge 13y ago

This is older than git 1.9, but git supports mercurial repositories[1]. I used to have to use mercurial to deal with kiln (which couldn't convert our repo to git), but now I happily work with git and everything is 10 times faster. [1]: https://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/ https://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2...

akxak 13y ago
When was the last time you used Mercurial? Git being 10 times faster seems dated. Especially if you're using Facebook's fabulous Mercurial extensions, which actually make Mercurial faster than Git. https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
- stuhood 13y ago
  There are no version numbers in those benchmarks, nor any way to reproduce them. So take them with a few grains of salt. In particular, how old was the version of git they were testing with? Were they using SSDs?
barbs 13y ago
I'm curious: where does this 10x speed increase come from? are you implying that git is inherently faster than mercurial? I've not actually used mercurial myself so I wouldn't know...
- herge 13y ago
  git status is 10 times faster on my machine for the same repository than hg status.