De ontwikkelaars achter Git hebben versie 2.51.0 van hun software uitgebracht. Met Git kunnen onder andere software- en projectontwikkelaars beheer en versiecontrole over data en broncode uitvoeren. Het programma kan worden gezien als een concurrent voor Subversion of Mercurial. Het heeft onder andere complete branching- en mergingfuncties en wordt onder de GPLv2 uitgegeven. De complete changelog voor deze uitgave is hier te vinden; dit zijn de belangrijkste veranderingen en verbeteringen:
Cruft-free multi-pack indexesReturning readers will have likely seen our coverage of cruft packs, multi-pack indexes (MIDXs), and reachability bitmaps. In case you’re new around here or otherwise need a refresher, here’s a brief overview:
Git stores repository contents as “objects” (blobs, trees, commits), either individually (“loose” objects, e.g.
$GIT_DIR/objects/08/10d6a05...) or grouped into “packfiles” ($GIT_DIR/objects/pack). Each pack has an index (*.idx) that maps object hashes to offsets. With many packs, lookups slow down toO(M*log(N)), (whereMis the number of packs in your repository, andNis the number of objects within a given pack).A MIDX works like a pack index but covers the objects across multiple individual packfiles, reducing the lookup cost to
O(log(N)), whereNis the total number of objects in your repository. We use MIDXs at GitHub to store the contents of your repository after splitting it into multiple packs. We also use MIDXs to store a collection of reachability bitmaps for some selection of commits to quickly determine which object(s) are reachable from a given commit1.However, we store unreachable objects separately in what is known as a “cruft pack”. Cruft packs were meant to exclude unreachable objects from the MIDX, but we realized pretty quickly that doing so was impossible. The exact reasons are spelled out in this commit, but the gist is as follows: if a once-unreachable object (stored in a cruft pack) later becomes reachable from some bitmapped commit, but the only copy of that object is stored in a cruft pack outside of the MIDX, then that object has no bit position, making it impossible to write a reachability bitmap.
Git 2.51 introduces a change to how the non-cruft portion of your repository is packed. When generating a new pack, Git used to exclude any object which appeared in at least one pack that would not be deleted during a repack operation, including cruft packs. In 2.51, Git now will store additional copies of objects (and their ancestors) whose only other copy is within a cruft pack. Carrying this process out repeatedly guarantees that the set of non-cruft packs does not have any object which reaches some other object not stored within that set of packs. (In other words, the set of non-cruft packs is closed under reachability.)
As a result, Git 2.51 has a new
Smaller packs with path walkrepack.MIDXMustContainCruftconfiguration which uses the new repacking behavior described above to store cruft packs outside of the MIDX. Using this at GitHub has allowed us to write significantly smaller MIDXs, in a fraction of the time, and resulting in faster repository read performance overall. (In our primary monorepo, MIDXs shrunk by about 38%, we wrote them 35% faster, and improved read performance by around 5%.) Give cruft-less MIDXs a try today using the newrepack.MIDXMustContainCruftconfiguration option. [source]In Git 2.49, we talked about Git’s new “name-hash v2” feature, which changed the way that Git selects pairs of objects to delta-compress against one another. The full details are covered in that post, but here’s a quick gist. When preparing a packfile, Git computes a hash of all objects based on their filepath. Those hashes are then used to sort the list of objects to be packed, and Git uses a sliding window to search between pairs of objects to identify good delta/base candidates.
Prior to 2.49, Git used a single hash function based on the object’s filepath, with a heavy bias towards the last 16 characters of the path. That hash function, dating back all the way to 2006, works well in many circumstances, but can fall short when, say, unrelated blobs appear in paths whose final 16 characters are similar. Git 2.49 introduced a new hash function which takes more of the directory structure into account2, resulting in significantly smaller packs in some circumstances.
Git 2.51 takes the spirit of that change and goes a step further by introducing a new way to collect objects when repacking, called “path walk”. Instead of walking objects in revision order with Git emitting objects with their corresponding path names along the way, the path walk approach emits all objects from a given path at the same time. This approach avoids the name-hash heuristic altogether and can look for deltas within groups of objects that are known to be at the same path.
As a result, Git can generate packs using the path walk approach that are often significantly smaller than even those generated with the new name hash function described above. Its timings are competitive even with generating packs using the existing revision order traversal. Try it out today by repacking with the new
Stash interchange format--path-walkcommand-line option. [source]If you’ve ever needed to switch to another branch, but wanted to save any uncommitted changes, you have likely used
git stash. The stash command stores the state of your working copy and index, and then restores your local copy to match whatever was inHEADat the time you stashed.If you’ve ever wondered how Git actually stores a stash entry, then this section is for you. Whenever you push something onto your stash, Git creates three3 commits behind the scenes. There are two commits generated which capture the staged and unstaged changes. The staged changes represent whatever was in your index at the time of stashing, and the working directory changes represent everything you changed in your local copy but didn’t add to the index. Finally, Git creates a third commit listing the other two as its parents, capturing the entire snapshot.
Those internally generated commits are stored in the special
refs/stashref, and multiple stash entries are managed with the reflog. They can be accessed withgit stash list, and so on. Since there is only one stash entry inrefs/stashat a time, it’s extremely cumbersome to migrate stash entries from one machine to another.Git 2.51 introduces a variant of the internal stash representation that allows multiple stash entries to be represented as a sequence of commits. Instead of using the first two parents to store changes from the index and working copy, this new representation adds one more parent to refer to the previous stash entry. That results in stash entries that contain four4 parents, and can be treated like an ordinary log of commits.
As a consequence of that, you can now export your stashes to a single reference, and then push or pull it like you would a normal branch or tag. Git 2.51 makes this easy by introducing two new sub-commands to git stash to import and export, respectively. You can now do something like:
$ git stash export --to-ref refs/stashes/my-stash $ git push origin refs/stashes/my-stashon one machine to push the contents of your stash to origin, and then:
$ git fetch origin '+refs/stashes/*:refs/stashes/*' $ git stash import refs/stashes/my-stashon another, preserving the contents of your stash between the two. [source]
:strip_exif()/i/2001706189.png?f=thumbmedium)