Skip to content

Git 2.55 Adds Incremental Repack, Parallel Hooks, and Linux Filesystem Monitor

Git 2.55 ships incremental multi-pack index repack support, parallel config-based hooks, a Linux fsmonitor via inotify, faster bitmap generation, and the git history fixup subcommand.

Git 2.55 release announcement graphic in white on GitHub orange
Git 2.55 · Credit: GitHub

Git 2.55 ships direct support for writing incremental multi-pack index (MIDX) chains from git repack, the most significant maintenance improvement in the release for teams running large repositories. The change, documented in GitHub's Git 2.55 release highlights authored by GitHub Principal Software Engineer Taylor Blau, addresses a long-standing cost: a single-file MIDX covers every pack in the object store, so even a minor update could force a full rewrite in an already-large repository. Running git repack --write-midx=incremental now appends a new MIDX layer for freshly written packs without touching older layers. Combined with geometric repacking (--geometric=2 -d), Git keeps the chain length logarithmic in the total object count by rewriting the newest, smallest layers more often while leaving older, larger ones untouched. The split factor is configurable via repack.midxSplitFactor, giving repository administrators control over the compaction trade-off.

Git 2.55 also adds the fixup subcommand to the experimental git history command that Git 2.54 introduced. The subcommand applies staged changes to an earlier commit without requiring a separate git commit --fixup followed by git rebase --autosquash: git history fixup <commit> folds the index into the target and replays descendants on top. The target commit keeps its message and authorship unless --reedit-message is passed. The command requires a working tree, cannot run in a bare repository, and aborts if applying the staged change would produce a merge conflict, rather than leaving a partial rewrite in progress.

Config-based hooks, which Git 2.54 added to move hook definitions from per-repository $GIT_DIR/hooks scripts into Git configuration, now support parallel execution in Git 2.55. Independent hooks, such as a linter and a unit-test runner, can declare hook.<name>.parallel = true to run concurrently. Concurrency is controlled globally via hook.jobs or per-event via hook.<event>.jobs; commit-message hooks and other hooks that read the index continue running serially. The same release extends the built-in filesystem monitor (core.fsmonitor) to Linux using the inotify kernel interface, a change that closes the gap that previously kept the daemon macOS- and Windows-only. Very large repositories on Linux may need to raise fs.inotify.max_user_watches because the daemon requires one inotify watch per directory.

Two performance improvements target expensive maintenance paths in Git 2.55. Reachability bitmap generation, which GitHub benchmarked falling from roughly 612 seconds to roughly 294 seconds, achieves those gains by avoiding unnecessary tree recursion, caching object positions, and reordering XOR operations. Pseudo-merge bitmaps, which group related Git references so Git can combine precomputed bit arrays during traversal, previously nearly doubled bitmap generation time while delivering up to 20x traversal speedups; the 2.55 changes narrow that generation overhead while preserving most of the traversal benefit. The git pack-objects --path-walk mode, introduced in Git 2.51 to improve delta compression via path locality, can now be combined with partial-clone filters including blob:none, blob:limit=<n>, and tree:0; a benchmark on the Git repository itself showed a blob-less path-walk repack producing a pack roughly 16 percent smaller.

Several smaller additions round out Git 2.55. The git push command now accepts the remote-group shorthand (remotes.<name>) that git fetch has long supported, letting teams push to GitHub, GitLab, and a mirror in sequence with one command. The git log --graph family gains --graph-lane-limit=<n>, which replaces lanes beyond the limit with a tilde to keep wide-history output readable. A new --max-count-oldest=<n> option for git rev-list and git log selects the oldest n commits directly, removing the need to format the full range and discard via tail. The experimental git format-rev command pretty-formats commits from standard input inside a pipeline, avoiding the per-row Git subprocess overhead that Junio C Hamano's example in the release post illustrates. Git also masks most terminal control sequences in sideband progress output by default while preserving ANSI color codes, closing an injection path that existed whenever a server could send arbitrary escape sequences to a connecting client. Git 2.55 draws contributions from more than 100 developers, 33 of them first-time contributors to the project.

Share this story

Stefan Holloway

Stefan Holloway covers programming languages, open-source ecosystems, and the CI/CD and API tooling that ships software for techshooked. He writes reproducibility-first, stating the version tested, showing the configuration, and separating a genuine workflow improvement from release-note marketing.