What's new in Git 2.55.0?

Published on: June 29, 2026 11 min read Learn about the new features and changes in Git 2.55, including a new git-history(1) fixup command, an fsmonitor daemon for Linux, pushing to remote groups, and more. The Git project recently released Git 2.55.0. Let's look at a few notable highlights from this release, which includes contributions from the Git team at GitLab. What's covered: fixup git push to a remote groupgit log --graph lane widthfixup In our highlights of Git 2.54.0, we covered the introduction of git-history(1). In 2.55.0, a new subcommand for this tool was added: fixup . Imagine you've made some changes and you want to amend those changes into an existing commit. The most common approach to this is to create a fixup commit and autosquash it with git-rebase(1): git commit --fixup=<commit-id> git rebase -i --autosquash <commit-id>^ Doing this in two steps is clumsy, especially because it requires an interactive rebase. Instead you can use the git-history(1) fixup command: git history fixup <commit-id> This takes the staged changes and amends them into the given commit. As an added bonus, because you're using git-history(1), all other local branches that contain the fixed-up commit are updated as well. So when working with stacked branches, fixup-ing a commit in the stack will automatically rebase all related branches. This feature was implemented by Patrick Steinhardt. When working with large monorepos, git-status(1) can be slow to determine what changed in the local worktree because Git would need to traverse the whole working tree to see which files are modified. To speed up this process, in January 2018 a setting core.fsmonitor was added in Git 2.16. Back then, you had to provide your own tool (like Watchman). When this was configured, this tool runs in the background and monitors changes on the file system. This informs Git that a file was touched and Git then verifies whether the file was modified and updates the cached status. Then whenever the user calls git-status(1), it can simply return the cached status. In April 2022, the setting core.fsmonitor was changed to accept a boolean value. When this setting is set to true , a daemon built-in into Git is used and no more third-party tool is needed. But this filesystem monitor was only implemented for Windows and macOS, support for GNU/Linux did not yet exist. This changes in Git 2.55, where support for Linux has been added, too. To achieve this, inotify(7) is used. inotify(7) was chosen over fanotify(7) because fanotify(7) requires elevated privileges. This comes with a small caveat though, the fsmonitor needs to put a watcher on each and every directory in the repository. In a large repo you might hit the limit of inotify watches (fs.inotify.max_user_watches ), which you may need to raise. These changes were submitted by Paul Tarjan based on work by Eric DeCosta and Marziyeh Esipreh. git push to a remote groupQuite some time ago git-fetch(1) learned to fetch from a group of remotes. The following command configures a group of remotes: git config set remotes.forks "origin upstream" When this is set up, you can git-fetch(1) from this "forks" group, and then all the remotes in that list are fetched from. This can be useful when you want to get the updates from a set of remotes in one go. git-push(1), however, was not able to use remote groups. In Git 2.55, this gap is closed and git-push(1) now accepts a remote group too. For example if you want to push the main branch to the group mentioned above: git push forks main Similar as with git-fetch(1), this command pushes the specified refs to each of the remotes in the group. Each remote is pushed independently and honors its own remote.<name>.push mapping and mirror settings. This feature was submitted by Usman Akinyemi, suggested by Junio C Hamano. git log --graph lane widthThe --graph option of git-log(1) draws an ASCII representation of the commit history. In a repository with many active contributors this graph can grow very wide. For example, on the git.git repository this graph grows nine lanes wide after only 30 commits: * 26d8d94e94 A few more topics before -rc2 * 02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more' |\ | * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs | * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers | * 188bac14f7 pack-objects: use size_t for in-core object sizes | * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t | * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long | * 33afe87338 patch-delta: use size_t for sizes | * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate * | 8cf57cbec4 Merge branch 'kw/gitattributes-typofix' |\ \ | * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts * | | 8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows' |\ \ \ | * | | ab3810eb6f zlib: properly clamp to uLong * | | | 95e20213fa Hopefully final batch before -rc2 * | | | 8632b5c49d Merge branch 'en/commit-graph-timestamp-fix' |\ \ \ \ | * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator * | | | | 619931f561 Merge branch 'dl/posix-unused-warning-clang' |\ \ \ \ \ | * | | | | cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison | * | | | | ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED | * | | | | 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang * | | | | | 621962aa7a Merge branch 'td/ls-files-pathspec-prefilter' |\ \ \ \ \ \ | * | | | | | 3f5203eeb4 ls-files: filter pathspec before lstat | | |_|_|_|/ | |/| | | | * | | | | | 0c706d5092 Merge branch 'ta/doc-config-adoc-fixes' |\ \ \ \ \ \ | * | | | | | 4fa2c6e045 doc: git-config: escape erroneous highlight markup | * | | | | | 042221cccb doc: config/sideband: fix description list delimiter | * | | | | | 3eb61fda62 doc: config: terminate runaway lists * | | | | | | 49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup' |\ \ \ \ \ \ \ | * | | | | | | e8f12e0e95 t1400: have fifo test clean after itself * | | | | | | | b4970f8448 Merge branch 'td/describe-tag-iteration' |\ \ \ \ \ \ \ \ | * | | | | | | | 55088ac8a4 describe: limit default ref iteration to tags This happens because every lane continues downward to the commit from where the branch was created. This pushes the commit messages off to the right, making it harder to read. Especially when the terminal screen width is reached, this becomes unusable. Git 2.55 adds a new --graph-lane-limit=<n> option to limit the number of lanes that are drawn. Any lanes beyond the limit are replaced with a ~ truncation mark, so it stays obvious that the graph was trimmed: git log --graph --graph-lane-limit=5 Using this option for the same 30 commits as above, we'll get: * 26d8d94e94 A few more topics before -rc2 * 02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more' |\ | * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs | * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers | * 188bac14f7 pack-objects: use size_t for in-core object sizes | * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t | * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long | * 33afe87338 patch-delta: use size_t for sizes | * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate * | 8cf57cbec4 Merge branch 'kw/gitattributes-typofix' |\ \ | * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts * | | 8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows' |\ \ \ | * | | ab3810eb6f zlib: properly clamp to uLong * | | | 95e20213fa Hopefully final batch before -rc2 * | | | 8632b5c49d Merge branch 'en/commit-graph-timestamp-fix' |\ \ \ \ | * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator * | | | | 619931f561 Merge branch 'dl/posix-unused-warning-clang' |\ \ \ \ \ | * | | | ~ cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison | * | | | ~ ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED | * | | | ~ 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang * | | | | ~ 621962aa7a Merge branch 'td/ls-files-pathspec-prefilter' |\ \ \ \ \~ | * | | | ~ 3f5203eeb4 ls-files: filter pathspec before lstat | | |_|_|_~ | |/| | | ~ * | | | | ~ 0c706d5092 Merge branch 'ta/doc-config-adoc-fixes' |\ \ \ \ \~ | * | | | ~ 4fa2c6e045 doc: git-config: escape erroneous highlight markup | * | | | ~ 042221cccb doc: config/sideband: fix description list delimiter | * | | | ~ 3eb61fda62 doc: config: terminate runaway lists * | | | | ~ 49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup' |\ \ \ \ \~ | * | | | ~ e8f12e0e95 t1400: have fifo test clean after itself * | | | | ~ b4970f8448 Merge branch 'td/describe-tag-iteration' |\ \ \ \ \~ | * | | | ~ 55088ac8a4 describe: limit default ref iteration to tags The option only makes sense together with --graph . The default is 0 , which means no limit, and zero or negative values are treated the same way, just like --max-parents does. This feature was submitted by Pablo Sabater. In March 2025, with the release of Git 2.49, the first Rust code was added to the Git codebase. Rust bindings were added to allow Rust code to call into libgit. But none of that Rust code was used by the Git binaries. In November 2025, in Git 2.52, the first Rust production code was introduced into Git. Then a Rust implementation for the varint subsystem was added. This code is optionally compiled if the Rust compiler is available, and when it's not, the C implementation is used. This was added as a test balloon for distributors to start preparing their tooling for a Git release that requires Rust at some point. Earlier this year, in Version 2.54, more Rust code was added to the codebase with the introduction of the ObjectID type. This was added as part of the efforts to implement interoperability between SHA-1 and SHA-256. Until this release, both build systems Make and Meson would gracefully fall back to the C implementation if the Rust compiler is not found. With this v2.55 release the Rust compiler is required unless you explicitly disable it in the build system. Please note that this doesn't affect users of Git. It only affects those who build Git from source. If you compile Git and don't want to use Rust, disable it with one of these commands: # Meson meson configure -Drust=disabled # Makefile make NO_RUST=YesPlease Bringing Rust into Git has been an ongoing (and unfinished), multi-release, community effort. It's impossible to attribute this to a single person, but some of the most prominent contributors include brian m. carlson, Patrick Steinhardt, Ezekiel Newren, and Calvin Wan. git-clone(1) has this feature called partial clone. This allows the user to apply a filter to what is sent over from the server. In practice, this is done with the --filter option. For example: git clone --filter=blob:none <remote> This will clone the repository, but that clone excludes all blobs (i.e. the contents of the files in the tree). This can speed up the clone tremendously, but it comes at the cost that Git needs to download blobs later when other commands are used that read file contents. And some commands might need a lot of missing blobs. git-grep(1) is one of those commands, as it searches the content of the files. To do so, it obviously needs to have those files. Imagine you want to search the word "TODO" 100 commits back in history: git grep TODO HEAD~100 This command resolves the HEAD~100 commit and the trees associated with that. But those trees might point to blobs that aren't downloaded yet. Previously, each blob was downloaded separately. But that is improved in Git 2.55. In this version of Git, the blob downloads are batched together into a single negotiating round-trip with the server. This batching is now implemented for both git-grep(1) and git-cherry(1). This change was submitted by Elijah Newren. This article highlighted just a few of the contributions made by GitLab and the wider Git community for this latest release. You can learn about these from the official release announcement of the Git project. Also, check out our previous Git release blog posts to see other past highlights of contributions from GitLab team members. Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback