Welcome to the 11th 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 December 2015.
Shawn Pearce, who is one of the main Git, JGit and Gerrit contributors, sent an email about a new ref storage backend saying:
I started playing around with the idea of storing references directly in Git. Exploiting the GITLINK tree entry, we can associate a name to any SHA-1.
and:
By exploiting Git to store Git, we get a reflog for free…
It’s interesting because there has been a lot of work during the past years to develop news ways to store refs. Especially there has been attempts to store refs in databases like LMDB, that have been covered in Git Rev News edition 7.
This new approach tries to store refs using git’s own object database that already stores blobs, trees, commits and tags.
It uses so called “gitlink” which are special tree entries that are used by git submodules to refer to commits in their host git repository.
Following some comments by Junio, Shawn agreed that his implementation has some hacks to handle “HEAD”, which is a special ref, and to handle the fact that gitlinks were made to only point to commits, not tags.
Michael Haggerty wondered if the negotiation phase that happens when doing a ‘git fetch’ could be sped up by such an implementation. This started a discussion between Shawn, Junio and Michael about how the “refs/” hierarchy could be improved.
Jeff King discussed with Shawn some other aspects like the reflog and reachability, and Shawn mentioned other advantages:
One advantage of this format is deleted branches can retain a reflog post deletion. Another is you can trivially copy the reflog using native Git to another system for backup purposes. Or fetch it over the network to inspect locally. So a shared group server could be exporting its reflog, you can fetch it and review locally what happened to branches without logging into the shared server.
Another advantage of this format over LMDB or TDB or whatever is Git already understands it. The tools already understand it. Plumbing can inspect and repair things. You can reflog the reflog using traditional reflog…
And it looks like Shawn has a bigger plan but don’t want to tell us too much for now.
Duy Nguyen sent a patch series that restarted previous work he had already done on splitting config options in two different sets. Some that are specific to each worktree and some that are not.
There are two pattern lists. One is a default pattern list built into the git binary, and the other one in “.git/info/config.worktree” is a user writable pattern list. Those two pattern lists are merged internally to specify which config options are worktree specific.
The worktree specific config options should then be put in “.git/worktrees/NAME/config.worktree” where NAME is a specific worktree’s name, while the other config options still stay in “.git/config”.
Eric Sunshine reviewed the patch series and as always asked pertinent questions on the naming of files, the code and the tests.
Max Kirillov first suggested the following:
Now there are extensions support, would it make sense to mark repositories which use per-worktree config with an extension?
Max is referred to the extension mechanism that has been released in the brand new Git 2.7.0 and that was mentioned in some places.
And Duy liked the idea of adding an extension for per-worktree config.
Max on the other hand said that having a default pattern list built into the git binary could be confusing for users and could be difficult to extend, but Duy and Junio didn’t agree with that.
From the following discussion, it looks like it is a complex issue to design something that is backward and forward compatible.
Apart from some minor releases, the major release last month was Git 2.7.0, arriving in Git and Git for Windows not long after. See the articles from Michael Haggerty and Tim Pettersen below for tours of the new features.
Other releases:
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>.