

Git 1.9 Release Notes - rjzzleep
https://raw.github.com/git/git/master/Documentation/RelNotes/1.9.0.txt

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

~~~
jbnicolai
Not really, an increment to the major version number simply indicates non
backwards-compatible API changes. See:
[http://semver.org/](http://semver.org/)

------
herge
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
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-
merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-
facebook/)

~~~
stuhood
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?

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

~~~
dfc
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)."

[https://wiki.documentfoundation.org/QA/HowToBibisect](https://wiki.documentfoundation.org/QA/HowToBibisect)

[http://cgit.freedesktop.org/libreoffice/contrib/dev-
tools/](http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/)

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

------
spindritf
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
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)

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

~~~
daenney
Perhaps emacs is to blame for that.

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

~~~
Flenser
[https://code.google.com/p/msysgit/downloads/list?q=full+1.9](https://code.google.com/p/msysgit/downloads/list?q=full+1.9)

------
gnoway
I appreciate the change to --tags.

------
tekacs
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/RelNote...](https://github.com/git/git/blob/master/Documentation/RelNotes/1.9.0.txt)

~~~
antirez
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
Neither link here did this for me in Chrome for iOS. Odd?

