Welcome to the 12th edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.
This edition covers what happened during the month of January 2016.
David Turner, who works for Twitter, recently sent new versions of his work to add a database backend to store Git refs:
This work was started a long time ago by Ronnie Sahlberg, working for Google, and has already been reported about in Git Rev News edition 7.
These last patch series have again been reviewed or commented on by a lot of experienced Git developers, like Junio Hamano, Michael Haggerty, Duy Nguyen, Shawn Pearce, Jonathan Nieder, Eric Sunshine, David Aguilar, Ronnie Sahlberg, Jeff King, Szeder Gábor, Thomas Gummerer, Ramsay Jones, and also a bit by Howard Chu the LMDB author.
Some suggestions were about:
So the interest in this work is still big and makes it likely that it will bear fruits hopefully soon.
Eric Wong, a long time git developer and the original git-svn author, reported that he couldn’t use the rsync protocol anymore to clone:
I have not used rsync remotes in ages, but I was working on the patch for -4/-6 support and decided to test it against rsync.kernel.org
Cloning git.git takes forever and failed with:
$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git Checking connectivity… fatal: bad object ecdc6d8612df80e871ed34bb6c3b01b20b0b82e6 fatal: remote did not send all necessary objects
Jeff King, alias Peff, replied that the “rsync transport blindly pulls all of the data over, with no idea that it doesn’t need most of it”, and as there are “over 95,000 unreachable loose objects consuming a gigabyte” in the cloned repository. This explains why Eric’s clone took forever.
But it also didn’t work for Eric with smaller repositories and with quite old versions of Git like 1.7.10.4. To that Peff replied that in the rsync code “we blindly concatenate the list of loose refs and packed refs” which has never been the right thing to do. And this explains why the clones always fail with rsync. Peff found that this has been broken since 2007, which is why it doesn’t work even with old git versions.
Peff also investigated different ways to fix it but concluded:
…git-over-rsync is just an awful protocol. Nobody should be using it. Having looked at it in more detail, I’m more in favor than ever of removing it.
and then sent a patch to “drop support for git-over-rsync”. This patch, on top of explaning the above, contains:
We never made an official deprecation notice in the release notes for git’s rsync protocol, but the tutorial has marked it as such since 914328a (Update tutorial., 2005-08-30). And on the mailing list as far back as Oct 2005, we can find Junio mentioning it as having “been deprecated for quite some time.”… So it was old news then; cogito had deprecated the transport in July of 2005… (though it did come back briefly when Linus broke git-http-pull!).
Of course some people professed their love of rsync through 2006, but Linus clarified in his usual gentle manner…:
Thanks! This is why I still use rsync, even though everybody and their mother tells me “Linus says rsync is deprecated.”
No. You’re using rsync because you’re actively doing something wrong.
The deprecation sentiment was reinforced in 2008, with a mention that cloning via rsync is broken (with no fix)…
Even the commit porting rsync over to C from shell (cd547b4) lists it as deprecated! So between the 10 years of informal warnings, and the fact that it has been severely broken since 2007, it’s probably safe to simply remove it without further deprecation warnings.
I’m an occasional contributor to Git. Originally I got involved with the Git community during the Google Summer of Code in 2012. I recently finished my masters degree, and will be starting a new job in about a month.
I haven’t really made any big contributions to Git, but rather the occasional bug fix and some small features. Many of my contributions are around the index, as that’s the first thing I worked on in Git for my Google Summer of Code project in 2012.
Most recently I helped reviewing the LMDB backend patch series by
David Turner. As I didn’t know much about the refs code before reading
through the series I thought the introduction of a new backend would
be a good way to learn more about that part of Git. Other recent work
includes a patch series to add an option to show symrefs in git
ls-remote and another patch series allowing git grep to fall back
to git grep --no-index, if it is executed outside of a git
repository. In addition to improving a project I use daily, I get to
learn from more experienced developers with each patch series I’m
sending.
One thing I particularly like about Git is how almost every operation
can be reversed in some way, if the user knows how to. Recovering from
such operations can however often be difficult, especially for someone
who does not know the ins and outs of Git. I think it would be great
to have some kind of git undo command, that can undo the last, or
last few operations in the repository.
I don’t think I would remove any feature in particular, but it would be nice to improve the consistency in the user interface. These inconsistencies make using Git harder and often confusing for new users.
From a contributor perspective I find Thomas Rast’s tbdiff very useful. I use it mostly to compare an older version of a patch series to a new version I’m about to send and to see if all the review comments are addressed.
Various
Light reading
Git tools and sites
This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Thomas Ferris Nicolaisen <tfnico@gmail.com> and Nicola Paolucci <npaolucci@atlassian.com>, with help from Thomas Gummerer, Johannes Schindelin and Jeff King.