Highlights from Git 2.55

The open source Git project just released Git 2.55 with features and bug fixes from over 100 contributors, 33 of them new. We last caught up with you on the latest in Git back when 2.54 was released . To celebrate this most recent release, here is GitHub’s look at some of the most interesting features and changes introduced since last time. Repacking with incremental multi-pack indexes Returning readers of this series may recall our coverage of incremental multi-pack indexes and incremental multi-pack reachability bitmaps . In case you could use a refresher, here’s the short version. Git stores the contents of your repository as individual objects : commits, trees, and blobs. Those objects usually live in packfiles , which are compressed collections of objects. A packfile has a corresponding pack index that lets Git locate any object inside the pack quickly. But large repositories do not usually have just one packfile: over time, fetches, pushes, maintenance tasks, and repacks can leave many packs behind. A multi-pack index (or MIDX) gives Git a single index over many packs. Instead of opening and searching each pack’s individual index, Git can ask the MIDX which pack contains a given object and at which offset. This is especially useful for large repositories, and it is one of the building blocks behind GitHub’s repository maintenance strategy. As we covered when Git 2.47 introduced the incremental MIDX format , a repository can store its MIDX as a chain of layers instead of as a single MIDX covering every pack. A single-file MIDX is simple and efficient to read, but it has an important maintenance cost; since that file includes every pack it covers, even a small update can require a large write in an already-large repository. Incremental MIDXs address that by storing a chain of MIDX layers. Each layer covers some collection of packs, and the chain file records the order of those layers. Appending a new layer to the tip of the chain does not invalidate the older la