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'.
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.
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.
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) that uses the git pack-file format with a rolling checksum algorithm to do fast deduplication within files.
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).
You really should "scold" the folks at LibreOffice. They have a neat tool that relies on checking large binary files into git. It is actually a neat development tool:
"bibisect stands for "binary bisect" and is intended to help LibreOffice QA dealing with regressions. Regressions are a most annoying artifact that unfortunately comes with software development and QA. However, regressions are a misfeature we want to deal with quick and early as they might get harder and harder to triage and fix as time passes.
Because the way git stores its stuff, one bibisect can contain several complete Linux 64-bit office installs in a very much compressed size.
And one does not need to install them in parallel as one can switch through all of them with a quick "git checkout source-hash-XXXXXX" -- one switch costs <1 second)."
yeah, well, that's entirely different from what we were talking about though. also speed is obviously not their focus. they just chose a comfortable approach to binary searching regressions in binary builds of libreoffice.
it's not a repo anyone will ever work with. some build bot builds it, and noone else ever commits things back. you just download the tar'd repo, and never ever commit anything or push back. it's also clearly seperated from any code repositories they have.
but maybe i misunderstood something so feel free to correct me.
Another thing that FB's solution did was to add inotify support. Git may get this feature soon -- there are already experimental patches on the mailing list for it.
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.
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.
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...
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
Might want to try this instead: https://github.com/git/git/blob/master/Documentation/RelNote...