Looking forward to Git 2.56 — and 3.0

What's in Git 2.56

The Git 2.56 release contains something over 700 non-merge commits; it brings a number of nice improvements, but will not fundamentally change the Git experience for most users. One feature that offers some potential in that regard is the addition of the drop subcommand to the (still experimental) git history toolbox:

    $ git history drop commit-id

This command will cause the identified commit to be removed from the history of the current branch, replaying all commits that were added after it. It offers an easier way of removing an offending commit. Unfortunately, it still refuses to work if the history contains merge commits, making it unusable for many (or most) repositories.

The git status command will now suggest a git pull command to update a branch that is behind the branch it tracks. It still, though, will say that a branch is "up to date" even if it lags behind an (unfetched) remote tracking branch.

The git refs command exists to manipulate references at a low level; in 2.56, it has gained a number of new subcommands. Those commands, create, delete, update, and rename, perhaps surprisingly for Git, do exactly what their names suggest they would.

There are a number of minor usability tweaks. The new --delete-merged option to git branch will remove local branches that have been merged into their remote tracking branches. An attempt to delete a branch with git branch -d will fail, with a useful message, if that branch is being used for bisection. Attempts to lock the configuration file will be retried on failures, avoiding annoyance when multiple commands try to modify the file at once. git add has a new --resolved option that only adds files with merge conflicts that have been resolved.

Beyond that, there is the usual long list of bug fixes, refactorings, and performance improvements. All told, 2.56 looks like a solid release, but it also shows the signs of a project that is holding back much of its more significant work for the future. That leads to the question of what comes next.

After 2.56?

In early September, Git maintainer Junio Hamano asked the community what the next release should be. Would it be best to put out the 3.0 release that the community has been working toward for some time, finishing the year on a high note? Or, instead, is there a need for one or more 2.x releases still before the 3.0 release can happen?

This is an important question, because 3.0 will contain a number of compatibility breaks that may make some users pause before upgrading. Of those, perhaps the most significant is the switch to using the SHA-256 hash function by default, rather than the SHA-1 hash that Git has used since the beginning. SHA-1 has long been deemed to be weak, which is worrisome for applications like Git. Hashes are used to identify every object (files, directory trees, commits) in the Git repository, and are used to verify the chain of commits leading to any given point. If SHA-1 can be broken, it can conceivably be used to modify the history of a repository in ways that are difficult or impossible to detect.

Git has long included defenses against the known SHA-1 attacks, and few people appear to be seriously worried about the potential for compromised repositories now. Still, it makes a lot of sense to move to a more secure hash function.

Non-experimental support for SHA-256 has existed in Git since the 2.42 release in 2023, though some of the glue for interoperating with older repositories has taken longer. The biggest concern that has kept the Git developers from moving to SHA-256 by default for some time now has been support (or the lack thereof) at the major forge sites. GitLab has had support since 2024, and Forgejo has support as well. The elephant that is still missing from this room, though, is GitHub; releasing a version of Git that creates GitHub-incompatible repositories is a worrisome prospect. It still is not clear when GitHub might add that support, but it is notable that brian m. carlson, a GitHub employee and a key developer behind the SHA-256 transition, responded to Hamano's question by saying that news on that topic was coming, and that having the next release be 3.0 might be the best choice.

That said, carlson has posted one other change that they would like to see added before 3.0 comes out. While Git has always managed hexadecimal numbers (specifically, object IDs) as lower-case strings, it has also accepted upper-case IDs. That leads to situations where two seemingly different IDs (f00f00 and F00F00, say) are actually the same. Seemingly, bugs and security vulnerabilities have arisen from this ambiguity. So carlson wants to change Git's behavior to only accept IDs in lower case. That is a change that, seemingly, should not cause problems for too many users, but there is almost certainly somebody somewhere who relies on that behavior.

Another significant change that has been waiting for the 3.0 release is the switch to the "reftable" mechanism. A reference (more commonly "ref") in Git is an association between a name and an object in the repository; branches, tags, and remotes are all refs, for example. Git currently (by default) stores each ref as a file under .git/refs/ in the repository. If a repository contains a branch called foo, there will be a file, .git/refs/heads/foo, containing the ID of the commit at the head of that branch. There is also a mechanism to pull all of these refs together into a packed-refs file, which increases performance — to a point.

This mechanism works, but becomes increasingly inefficient as the number of refs grows. In some projects, the number of refs does indeed grow. According to the project's reftable documentation, the Android repository contains over 800,000 refs. At that scale, looking up refs, or determining whether any refs pointing to a specific commit exist, can be an expensive operation. Slowing down development can be a yellow-card-level annoyance, leading to a desire to do something about the refs.

The Git 2.45 release added reftables as a more efficient way of storing refs. It is a binary file optimized for both space efficiency and quick access. Since then, it has been possible to create a repository that uses a reftable rather than the old file-based mechanism, but that has never been the default. Switching to reftable should have no visible consequences (other than better performance) for users of Git itself, but it can be a problem for users of other software packages that access Git repositories. In his email, carlson mentioned libgit2 as a potential concern.

As it turns out, libgit2 will not be a blocker here; Patrick Steinhardt let it be known that he has added reftable support to libgit2, and that SHA-256 support had been enabled by default in August. So libgit2 should be ready for the Git 3.0 transition.

Finally, as mentioned by carlson, there is the Rust question. The project has added some trial support for code written in Rust, but has hesitated to make Rust mandatory for the building of Git. That, too, is expected to change in the 3.0 release; after that, any platform that does not have a working Rust compiler will be unable to upgrade.

After listing these concerns, carlson suggested that they probably should not hold up the 3.0 release:

I think anyone else who is not already extremely far along on SHA-256 (and reftable, for software working with local repositories) is likely not worth considering. JGit and Gitoxide were both informed that SHA-256 was coming in Git 3.0 at least a year ago, for instance. (I know because I did the informing.)

Similarly, I am not aware of anyone who is seriously undertaking Rust support for platforms that do not already support it, so I don't think that should be a blocker, either.

That led to their conclusion that, most likely, designating the next release as 3.0 would be the best choice.

What will actually happen has not, yet, been announced publicly; that is waiting for Hamano to make a decision. As he put it: "this is not a popularity contest, nor is it even a democracy". In the nearly two weeks since his query was posted, though, there has been no strong opposition to moving into the 3.x era and leaving some of Git's early design decisions behind (though, naturally, repositories using SHA-1 and lacking reftables will continue to be fully supported). If the 3.0 release does not happen in 2026, it seems certain to show up shortly thereafter.

Update: at Kernel Recipes, Steinhardt described the plan that had been agreed to regarding releases. The December 2026 release will be called 2.98, as a signal that the 3.0 transition is coming. The 2.99 release will follow in April 2027; that will be a long-term-support release. Git 3.0 will also be released at the same time, and will be the base for all subsequent releases.

git log --graph --oneline branchA origin/branchA branchB origin/branchB HEAD

$ git merge-base HEAD master | xargs -I{} git log --oneline {}..master | cut -f1 -d' ' | tac | xargs -L1 git rebase

#!/bin/bash

set -Eeufo pipefail;

git merge-base HEAD "$1" \
| xargs -I{} git log --oneline {}.."$1" \
| cut -f1 -d' ' \
| tac \
| while read -r c; do
	git rebase "$c";
done;

$ cat cat src/bin/git-bisect-rebase
#!/bin/bash
# Copyright 2026, Alejandro Colomar <alx@kernel.org>
# SPDX-License-Identifier: GPL-3.0-or-later

set -Eeufo pipefail;
shopt -s lastpipe;

tgt="$(git rev-list -1 "$1")";

## Try a regular rebase.
if
	git rebase "$tgt" >/dev/null 2>/dev/null;
	test $? -eq 0;
then
	echo 'Successfully rebased.';
	exit 0;
else
	git rebase --abort >/dev/null 2>/dev/null;

	git merge-base HEAD "$tgt" \
	| xargs -I{} git rev-list {}.."$tgt" \
	| wc -l \
	| xargs -I{} printf '%s' "{} commits left to test in the target branch";
	printf '%s' " (trying $tgt)";
	echo ' [conflict]';
fi;

## Bisect.
while
	git merge-base HEAD "$tgt" \
	| xargs -I{} git rev-list {}.."$tgt" \
	| wc -l \
	| read -r n;

	test $n -gt 1;
do
	if
		git merge-base HEAD "$tgt" \
		| xargs -I{} git rev-list {}.."$tgt" \
		| sed "$(echo "($n + 2) / 2" | bc)!d" \
		| read -r mid;

		printf '%s' "$(expr $n - 1) commits left to test in the target branch";
		printf '%s' " (trying $mid)";

		git rebase $mid >/dev/null 2>/dev/null;

		test $? -eq 0;
	then
		echo ' [ok]';
	else
		echo ' [conflict]';

		tgt="$(git rev-list -1 "$mid")";
		git rebase --abort >/dev/null 2>/dev/null;
	fi;
done;

## Perform the conflicting rebase
echo "The conflict is at $tgt; about to rebase now.";
git rebase "$tgt";

$ git bisect-rebase agetpass
215 commits left to test in the target branch (trying fff90f9bbbf10e6d983b0a6b378d5da8ee967856) [conflict]
214 commits left to test in the target branch (trying 0482fd5f353c473268aff39e38513df2fb589a52) [conflict]
107 commits left to test in the target branch (trying b21a76f759492f88388840d69f85b8d27ad5dffe) [conflict]
53 commits left to test in the target branch (trying db3ca9f917efff9e2dab2fe36fa02fd6ef81ab08) [ok]
26 commits left to test in the target branch (trying 4df3f783c4d936e6985590981a2ddaf0377a3785) [ok]
12 commits left to test in the target branch (trying 93c675ef030e4eb226f60a317f3759755cd5bc5d) [ok]
5 commits left to test in the target branch (trying b4adbe6387ae8d95dbe0bd547a157492842bea12) [conflict]
2 commits left to test in the target branch (trying f7c712c3ade10c1d14916ea44408e42495fd1a8a) [conflict]
1 commits left to test in the target branch (trying 0bb39793716a2466aa1f477e4634e9d86532df80) [ok]
The conflict is at f7c712c3ade10c1d14916ea44408e42495fd1a8a; about to rebase now.
Auto-merging src/gpasswd.c
Auto-merging src/newgrp.c
CONFLICT (content): Merge conflict in src/newgrp.c
Auto-merging src/passwd.c
CONFLICT (content): Merge conflict in src/passwd.c
error: could not apply 6d0e130d5f3b... lib/, src/: Use getpassa()/passzero() instead of agetpass()/erase_pass()
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply 6d0e130d5f3b... # lib/, src/: Use getpassa()/passzero() instead of agetpass()/erase_pass()

$ cat src/bin/git-brebase 
#!/bin/bash
# Copyright 2026, Alejandro Colomar <alx@kernel.org>
# SPDX-License-Identifier: GPL-3.0-or-later

set -Eeufo pipefail;
shopt -s lastpipe;

if test $# -lt 1; then
	>&2 printf '%s\n' "$(basename "$0"): error: Too few arguments."
	exit 1;
fi;

if test $# -gt 1; then
	>&2 printf '%s\n' "$(basename "$0"): error: Too many arguments."
	exit 1;
fi;

git rev-list -1 "$1" \
| read -r tgt;

git rev-parse --abbrev-ref HEAD \
| read -r b;

## Try a regular rebase.
if
	git rebase "$tgt" >/dev/null 2>/dev/null;
	test $? -eq 0;
then
	echo 'Successfully rebased.';
	exit 0;
else
	git rebase --abort >/dev/null 2>/dev/null;
fi;

## Bisect.
git rev-parse --abbrev-ref HEAD \
| read -r b;
git bisect start >/dev/null;
git bisect bad "$tgt" >/dev/null;
git merge-base HEAD "$tgt" \
| xargs -I{} git bisect good {};

while
	git rev-list -1 HEAD \
	| read -r tgt;

	git bisect visualize --oneline \
	| wc -l \
	| xargs -I{} test {} -gt 1;
do
	git switch "$b" >/dev/null 2>/dev/null;

	if
		git rebase "$tgt" >/dev/null 2>/dev/null;
		test $? -eq 0;
	then
		echo 'Rebase: success';
		git bisect good "$tgt";
	else
		echo 'Rebase: conflict';
		git rebase --abort >/dev/null 2>/dev/null;
		git bisect bad "$tgt";
	fi;
done;

git bisect next \
| sed '1!d' \
| cut -f1 -d' ' \
| read -r tgt;

git bisect reset >/dev/null;

## Perform the conflicting rebase
git rebase "$tgt";

$ git brebase c
Bisecting: 8 revisions left to test after this (roughly 3 steps)
[7a5303be9b6be4e9c00fa714e8e2a236f655e0c5] lib/: Use '(void)' to define a function with 0 parameters
Rebase: conflict
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[bb2d8fa5b96f32f900b1631170bd875e6f0b3c62] src/login.c: main(): Wrap uses of 'subroot' in ifndef USE_PAM
Rebase: conflict
Bisecting: 1 revision left to test after this (roughly 1 step)
[b4adbe6387ae8d95dbe0bd547a157492842bea12] lib/io/syslog.h: SYSLOGE[C](): Add macros
Rebase: conflict
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[f7c712c3ade10c1d14916ea44408e42495fd1a8a] lib/, tests/: Use fprinte() instead of its pattern
Rebase: conflict
f7c712c3ade10c1d14916ea44408e42495fd1a8a is the first 'bad' commit
commit f7c712c3ade10c1d14916ea44408e42495fd1a8a
Author: Alejandro Colomar <alx@kernel.org>
Date:   2025-07-23 17:39:19 +0200

    lib/, tests/: Use fprinte() instead of its pattern
    
    While we don't use it directly in tests/, exit_if_null_() uses it, so we
    need to link to it in its test.
    
    Signed-off-by: Alejandro Colomar <alx@kernel.org>

 lib/addgrps.c          |   4 +--
 lib/chowntty.c         |  10 ++++----
 lib/commonio.c         |  35 ++++++++++---------------
 lib/exit_if_null.h     |   4 +--
 lib/find_new_gid.c     |   9 +++----
 lib/find_new_uid.c     |   7 +++--
 lib/get_pid.c          |   8 +++---
 lib/gettime.c          |   8 +++---
 lib/idmapping.c        |  14 +++++-----
 lib/prefix_flag.c      |   7 +++--
 lib/root_flag.c        |  21 +++++++--------
 lib/run_part.c         |  12 ++++-----
 lib/selinux.c          |   6 ++---
 lib/spawn.c            |  14 +++++-----
 lib/tcbfuncs.c         | 134 ++++++++++++++++++++++++++++++++++++++---------------------------------------------------------
 src/chage.c            |   5 ++--
 src/chgpasswd.c        |   9 +++----
 src/chpasswd.c         |   9 +++----
 src/faillog.c          |  18 +++++--------
 src/free_subid_range.c |   4 +--
 src/get_subid_owners.c |   4 +--
 src/getsubids.c        |   4 +--
 src/gpasswd.c          |   6 ++---
 src/groupadd.c         |   7 +++--
 src/lastlog.c          |  10 +++-----
 src/login.c            |   4 +--
 src/new_subid_range.c  |   4 +--
 src/newgidmap.c        |  22 +++++-----------
 src/newgrp.c           |  11 ++++----
 src/newuidmap.c        |  10 +++-----
 src/newusers.c         |  43 +++++++++++++++----------------
 src/passwd.c           |  12 ++++-----
 src/useradd.c          |  63 ++++++++++++++++++---------------------------
 src/userdel.c          |  22 +++++-----------
 src/usermod.c          |  60 ++++++++++++++++++-------------------------
 src/vipw.c             |  20 ++++++---------
 36 files changed, 264 insertions(+), 376 deletions(-)
Already on 'opt'
Auto-merging lib/addgrps.c
CONFLICT (content): Merge conflict in lib/addgrps.c
Auto-merging lib/chowntty.c
Auto-merging lib/commonio.c
Auto-merging lib/find_new_gid.c
error: could not apply d5f8eeda09da... lib/: Propagate _Optional
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply d5f8eeda09da... # lib/: Propagate _Optional

$ cat src/bin/git-brebase 
#!/bin/bash
# Copyright 2026, Alejandro Colomar <alx@kernel.org>
# SPDX-License-Identifier: GPL-3.0-or-later

set -Eeufo pipefail;
shopt -s lastpipe;

err()
{
	>&2 printf '%s\n' "$(basename "$0"): error: $*";
	exit 1;
}

# Defaults:
fp='';
other='';

while test $# -ge 1; do
	case "$1" in
	--first-parent)
		fp='--first-parent';
		;;
	-*)
		other="$other $1";
		;;
	*)
		break;
		;;
	esac;
	shift;
done;
gbopts="$fp";
gropts="$other";

if test $# -lt 1; then
	err 'Missing target commit';
fi;
if test $# -gt 1; then
	err 'Too many arguments.';
fi;
git rev-list -1 "$1" \
| read -r tgt;

# Try a regular rebase.
if
	# shellcheck disable=SC2086  # gropts may hold multiple options
	git rebase $gropts "$tgt" 2>&1 >/dev/null\
	| read -r out;
	test $? -eq 0;
then
	echo "$out" >&2;
	exit 0;
else
	echo 'Rebase: conflict';
	git rebase --abort >/dev/null;
fi;

# Bisect.
# shellcheck disable=SC2248  # gbopts may hold multiple options
git bisect start --no-checkout $gbopts >/dev/null;
git bisect bad "$tgt" >/dev/null;
git merge-base HEAD "$tgt" \
| xargs -I{} git bisect good {};

while
	git bisect visualize --oneline \
	| wc -l \
	| xargs -I{} test {} -gt 1;
do
	if
		# shellcheck disable=SC2086  # gropts may hold multiple options
		git rebase $gropts BISECT_HEAD >/dev/null 2>/dev/null;
		test $? -eq 0;
	then
		echo 'Rebase: success';
		git bisect good BISECT_HEAD;
	else
		echo 'Rebase: conflict';
		git rebase --abort >/dev/null;
		git bisect bad BISECT_HEAD;
	fi;
done;

git rev-list -1 bisect/bad \
| read -r bad;
git bisect reset >/dev/null 2>/dev/null;

# Perform the conflicting rebase
# shellcheck disable=SC2086  # gropts may hold multiple options
git rebase $gropts "$bad";

$ git checkout <some-rev-in-the-middle>
$ git branch wip/newthing/base
$ git checkout -b wip/newthing/v1
/// ... hack hack hack, commit, hack hack hack, commit, send-email ...
$ git checkout -b wip/newthing/v2
$ git rebase -i wip/newthing/base
// ... reshuffle things, edit some commits, hack some more, range-diff, send-email ...
$ git checkout -b wip/newthing/v3
// ... rinse, repeat ...

git fetch origin refs/merge-requests/ID/head
git checkout FETCH_HEAD
# Make fixes
git remote add gl/$username gitlab:$username/$project.git # With the hope they show up again :)
git push gl/$username --force-with-lease HEAD:$upstream_name

#!/bin/sh -e
# tree filtering script
export rewritten_parent="$1"
set -- $(git rev-list -1 --parents "$GIT_COMMIT")
if test "$#" -ge 3; then
        if ! git revert -n "$offending"; then
                echo "stopped at merge $GIT_COMMIT" >&2
                bash </dev/tty >/dev/tty 2>/dev/tty
        fi
else
        GIT_ALLOW_NULL_SHA1=1 git read-tree -i -m $rewritten_parent
        git checkout-index -f -u -a || exit 1
        git clean -dqfx
        if test "$GIT_COMMIT" != "$offending"; then
                if ! git cherry-pick -n ${GIT_COMMIT}^..${GIT_COMMIT}; then
                        echo "stopped at $GIT_COMMIT" >&2
                        bash </dev/tty >/dev/tty 2>/dev/tty
                fi
        fi
fi

#!/bin/sh
export offending="$(git rev-parse "$1")"
FILTER_BRANCH_SQUELCH_WARNING=1 git filter-branch \
        --tree-filter '/tmp/ghd/tf $(map $(git rev-parse $GIT_COMMIT^))' \
        --msg-filter /tmp/ghd/mf $offending^..master