What will come after Git 2.56?
13 messages between Sep 6, 2026 and Sep 28, 2026, from Junio C Hamano, brian m. carlson, Patrick Steinhardt, Emily Shaffer, rsbecker@nexbridge.com, Harald Nordgren, Kristoffer Haugsbakk, D. Ben Knoble, Phillip Wood, Jeff King.
Plain Markdown or JSON for tools and agents.
http://tinyurl.com/gitcal tells us that the current development cycle for Git 2.56 will conclude around the end of this month. As our typical development cycle lasts between 8 and 12 weeks, we will have exactly one more cycle after that before the end of the year.
Now, the question is what that release should be called. A few thoughts.
(1) Git 3.0: it is tempting to conclude the year with a big
version bump. Splash! (2) Git 2.99: by leaving no more room until 3.0, we will
conclude the year with a version that is still in the 2.X
series, but will hopefully force us to seriously prepare for
a big version bump with the first release of the year 2027. (3) Git 2.98 (or 2.97): we admit that we are not ready for even
(2) and chicken out, leaving us breathing room for a few
more preparatory releases before the big one. (4) Git 2.57: doing business as usual.
Needless to say, this is not a popularity contest, nor is it even a democracy. Regardless, we should review what we have in the 'BreakingChanges' document and ask ourselves how ready we are.
Re: What will come after Git 2.56?
On 2026-09-06 at 07:03:20, Junio C Hamano wrote:
Show 25 quoted lines
> http://tinyurl.com/gitcal tells us that the current development
> cycle for Git 2.56 will conclude around the end of this month. As
> our typical development cycle lasts between 8 and 12 weeks, we will
> have exactly one more cycle after that before the end of the year.
>
> Now, the question is what that release should be called. A few
> thoughts.
>
> (1) Git 3.0: it is tempting to conclude the year with a big
> version bump. Splash!
>
> (2) Git 2.99: by leaving no more room until 3.0, we will
> conclude the year with a version that is still in the 2.X
> series, but will hopefully force us to seriously prepare for
> a big version bump with the first release of the year 2027.
>
> (3) Git 2.98 (or 2.97): we admit that we are not ready for even
> (2) and chicken out, leaving us breathing room for a few
> more preparatory releases before the big one.
>
> (4) Git 2.57: doing business as usual.
>
> Needless to say, this is not a popularity contest, nor is it even a
> democracy. Regardless, we should review what we have in the
> 'BreakingChanges' document and ask ourselves how ready we are.
There are a few remaining things I think we should consider in regards to this:
* forge support for SHA-256 on the remaining major forges (I have an
update to provide about this at Git Merge);
* any updates on libgit2 and its support for SHA-256 and reftable; and
* the lowercase-only object IDs series, which I will be sending out a
re-roll for today or tomorrow and which is a breaking change that we
may want to soak for a release or two.
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.
So my gut reaction would be that maybe 3 is the best choice. 2.97 might be nice, or we could be more careful and go with 2.95 and then skip ahead to 3.0 whenever we're ready.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
Re: What will come after Git 2.56?
On Sun, Sep 06, 2026 at 06:14:40PM +0000, brian m. carlson wrote:
Show 16 quoted lines
> On 2026-09-06 at 07:03:20, Junio C Hamano wrote:
> > http://tinyurl.com/gitcal tells us that the current development
> > cycle for Git 2.56 will conclude around the end of this month. As
> > our typical development cycle lasts between 8 and 12 weeks, we will
> > have exactly one more cycle after that before the end of the year.
> >
> > Now, the question is what that release should be called. A few
> > thoughts.
> >
> > (1) Git 3.0: it is tempting to conclude the year with a big
> > version bump. Splash!
> >
> > (2) Git 2.99: by leaving no more room until 3.0, we will
> > conclude the year with a version that is still in the 2.X
> > series, but will hopefully force us to seriously prepare for
> > a big version bump with the first release of the year 2027.
Well, same as there's room after Git 2.9 we also still have room after Git 2.99. No reason we cannot have Git 2.100. :)
Show 15 quoted lines
> > (3) Git 2.98 (or 2.97): we admit that we are not ready for even
> > (2) and chicken out, leaving us breathing room for a few
> > more preparatory releases before the big one.
> >
> > (4) Git 2.57: doing business as usual.
> >
> > Needless to say, this is not a popularity contest, nor is it even a
> > democracy. Regardless, we should review what we have in the
> > 'BreakingChanges' document and ask ourselves how ready we are.
>
> There are a few remaining things I think we should consider in regards
> to this:
>
> * forge support for SHA-256 on the remaining major forges (I have an
> update to provide about this at Git Merge);
Yeah, GitHub is the biggest question mark for me, and I wouldn't want to pull the trigger before it supports it. So I'm looking forward to your update!
> * any updates on libgit2 and its support for SHA-256 and reftable; and
I have upstreamed support for reftables into libgit2 now [1]. And SHA256 support was default-enabled in [2] now, which was merged roughly a month ago. So once the next release is out I think both of these blockers should be removed.
Patrick
[1]: https://github.com/libgit2/libgit2/pull/7117 [2]: https://github.com/libgit2/libgit2/pull/7261
Re: What will come after Git 2.56?
On Sun, Sep 6, 2026 at 8:19 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:
Show 33 quoted lines
>
> On 2026-09-06 at 07:03:20, Junio C Hamano wrote:
> > http://tinyurl.com/gitcal tells us that the current development
> > cycle for Git 2.56 will conclude around the end of this month. As
> > our typical development cycle lasts between 8 and 12 weeks, we will
> > have exactly one more cycle after that before the end of the year.
> >
> > Now, the question is what that release should be called. A few
> > thoughts.
> >
> > (1) Git 3.0: it is tempting to conclude the year with a big
> > version bump. Splash!
> >
> > (2) Git 2.99: by leaving no more room until 3.0, we will
> > conclude the year with a version that is still in the 2.X
> > series, but will hopefully force us to seriously prepare for
> > a big version bump with the first release of the year 2027.
> >
> > (3) Git 2.98 (or 2.97): we admit that we are not ready for even
> > (2) and chicken out, leaving us breathing room for a few
> > more preparatory releases before the big one.
> >
> > (4) Git 2.57: doing business as usual.
> >
> > Needless to say, this is not a popularity contest, nor is it even a
> > democracy. Regardless, we should review what we have in the
> > 'BreakingChanges' document and ask ourselves how ready we are.
>
> There are a few remaining things I think we should consider in regards
> to this:
>
> * forge support for SHA-256 on the remaining major forges (I have an
> update to provide about this at Git Merge);
Looking forward to it; support missing from GitHub is probably the thing that leaves me the most concerned about landing 3.0. On the one hand, the Git project is of course independent from GitHub, but on the other hand, pragmatically speaking, the majority of our users still host there, and it will be potentially quite confusing for people creating a new repo and trying to push.
However if there isn't a solid commitment on timeline from GitHub then it's less appealing to wait - it seemed like a lot of the work that was happening in 2026 was because of the looming pressure of 3.0 coming out in the fall.
Show 10 quoted lines
> * any updates on libgit2 and its support for SHA-256 and reftable; and
> * the lowercase-only object IDs series, which I will be sending out a
> re-roll for today or tomorrow and which is a breaking change that we
> may want to soak for a release or two.
>
> 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.)
I believe GitOxide received some initial support this year and I'm expecting for that work to continue over the next handful of months, FWIW.
As an aside - Google cares about landing it in GitOxide because jj also needs it to support SHA-256... but even with GitOxide support there is still some work to happen in jj itself to make it work. We are working on it but it's not ready still, fwiw.
Show 8 quoted lines
>
> 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.
>
> So my gut reaction would be that maybe 3 is the best choice. 2.97 might
> be nice, or we could be more careful and go with 2.95 and then skip
> ahead to 3.0 whenever we're ready.
For what it's worth, for our Google distribution I think we would disable SHA-256 for new repos via system config until we have GitHub support (and honestly probably JGit support), anyway. So that makes me want to say "meh, I don't care, why not release 3.0"... but not everyone has the luxury of distributing the system config to a whole swath of people like we do.
> --
> brian m. carlson (they/them)
> Toronto, Ontario, CA
RE: What will come after Git 2.56?
On September 6, 2026 2:15 PM, brian m. carlson wrote:
Show 45 quoted lines
>On 2026-09-06 at 07:03:20, Junio C Hamano wrote:
>> http://tinyurl.com/gitcal tells us that the current development cycle
>> for Git 2.56 will conclude around the end of this month. As our
>> typical development cycle lasts between 8 and 12 weeks, we will have
>> exactly one more cycle after that before the end of the year.
>>
>> Now, the question is what that release should be called. A few
>> thoughts.
>>
>> (1) Git 3.0: it is tempting to conclude the year with a big
>> version bump. Splash!
>>
>> (2) Git 2.99: by leaving no more room until 3.0, we will
>> conclude the year with a version that is still in the 2.X
>> series, but will hopefully force us to seriously prepare for
>> a big version bump with the first release of the year 2027.
>>
>> (3) Git 2.98 (or 2.97): we admit that we are not ready for even
>> (2) and chicken out, leaving us breathing room for a few
>> more preparatory releases before the big one.
>>
>> (4) Git 2.57: doing business as usual.
>>
>> Needless to say, this is not a popularity contest, nor is it even a
>> democracy. Regardless, we should review what we have in the
>> 'BreakingChanges' document and ask ourselves how ready we are.
>
>There are a few remaining things I think we should consider in regards to this:
>
>* forge support for SHA-256 on the remaining major forges (I have an
> update to provide about this at Git Merge);
>* any updates on libgit2 and its support for SHA-256 and reftable; and
>* the lowercase-only object IDs series, which I will be sending out a
> re-roll for today or tomorrow and which is a breaking change that we
> may want to soak for a release or two.
>
>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.
Actually, I may have some news on that score. While it is unlikely to make 3.0, it could be soon after. Unfortunately, all info is NDA, so I cannot really publicise it at this point. I remain very hopeful.
>So my gut reaction would be that maybe 3 is the best choice. 2.97 might be nice, or
>we could be more careful and go with 2.95 and then skip ahead to 3.0 whenever
>we're ready.
Re: What will come after Git 2.56?
On 2026-09-08 at 15:46:16, rsbecker@nexbridge.com wrote:
Show 8 quoted lines
> On September 6, 2026 2:15 PM, brian m. carlson wrote:
> >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.
>
> Actually, I may have some news on that score. While it is unlikely to make 3.0, it
> could be soon after. Unfortunately, all info is NDA, so I cannot really publicise it
> at this point. I remain very hopeful.
I'm very pleased to hear that some progress might be being made. I, too, am hopeful that NonStop or other platforms might provide a suitable Rust port that would work with Git.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
Re: What will come after Git 2.56?
> Well, same as there's room after Git 2.9 we also still have room after
> Git 2.99. No reason we cannot have Git 2.100. :)
I agree completely, no need signal that 3.0 is coming until it comes. Once it's out, not a soul will question what number the release just before had.
I have a list of breaking changes that I would like to introduce, I was hoping they could be considered before 3.0 is out -- otherwise I fear I have to wait another 10 years for 4.0, I would like to change the default values of these config values:
# Autostash by default
checkout.autostash=true
rebase.autostash=true # User friendlier branch sorting
branch.sort=-committerdate
tag.sort=-version:refname # Better diffing
diff.algorithm=histogram
diff.colormoved=zebra
diff.compactionheuristic=true # Compare branches on when push/upstream are different
status.comparebranches=@{upstream} @{push}It seemed a bit presumptuous to submit these as a patch, but maybe I should to open the formal discussion?
Harald
Re: What will come after Git 2.56?
Harald Nordgren <haraldnordgren@gmail.com> writes:
Show 5 quoted lines
>> Well, same as there's room after Git 2.9 we also still have room after
>> Git 2.99. No reason we cannot have Git 2.100. :)
>
> I agree completely, no need signal that 3.0 is coming until it comes. Once it's
> out, not a soul will question what number the release just before had.
I am afraid you totally misunderstand what we are doing. Once it is out nobody would care, but that completely misses the point.
By giving "Something big is coming" beforehand, we are warning downstream projects and distributions an advance warning and that begins with the jump from 2.5X to 2.98.
> I have a list of breaking changes that I would like to introduce, I was hoping
> they could be considered before 3.0 is out -- otherwise I fear I have to wait
> another 10 years for 4.0, I would like to change the default values of these
> config values:
I do not know how long it will be before 4.0, but if you do not have any draft code on the list or even design presented before this message, it is way too late for 3.0. No, these won't be part of it.
But some may not even qualify as "breaking changes", so after 3.0, some of them may not have to wait until 4.0 happens.
Re: What will come after Git 2.56?
On Thu, Sep 24, 2026, at 20:35, Harald Nordgren wrote:
Show 29 quoted lines
>> Well, same as there's room after Git 2.9 we also still have room after
>> Git 2.99. No reason we cannot have Git 2.100. :)
>
> I agree completely, no need signal that 3.0 is coming until it comes. Once it's
> out, not a soul will question what number the release just before had.
>
> I have a list of breaking changes that I would like to introduce, I was hoping
> they could be considered before 3.0 is out -- otherwise I fear I have to wait
> another 10 years for 4.0, I would like to change the default values of these
> config values:
>
> # Autostash by default
> checkout.autostash=true
> rebase.autostash=true
>
> # User friendlier branch sorting
> branch.sort=-committerdate
> tag.sort=-version:refname
>
> # Better diffing
> diff.algorithm=histogram
> diff.colormoved=zebra
> diff.compactionheuristic=true
>
> # Compare branches on when push/upstream are different
> status.comparebranches=@{upstream} @{push}
>
> It seemed a bit presumptuous to submit these as a patch, but maybe I should to
> open the formal discussion?Changing defaults is difficult. The code changes might be small but you have to convince many people that the potential disruption is worth it.
On the other hand, or on the opposite side of the spectrum, a tool that can read your configuration and recommend better settings would be more difficult to implement but could be easier to get buy-in for. This would be the next step up from hardcore Git users and folklore spreading through blogs and whatnot, thousands of users setting their version controlled (of course!?) global Git config one advice and word of mouth at a time. Just a plain old program that reads what you have, makes a report on the tiny little part that modern Git practice has an opinion on, and recommends the modern alternatives.
I have of course seen this idea on this list before.
Re: What will come after Git 2.56?
On Thu, Sep 24, 2026 at 9:21 PM Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote:
>
> On Thu, Sep 24, 2026, at 20:35, Harald Nordgren wrote:
Show 9 quoted lines
> On the other hand, or on the opposite side of the spectrum, a tool that
> can read your configuration and recommend better settings would be more
> difficult to implement but could be easier to get buy-in for. This would
> be the next step up from hardcore Git users and folklore spreading
> through blogs and whatnot, thousands of users setting their version
> controlled (of course!?) global Git config one advice and word of mouth
> at a time. Just a plain old program that reads what you have, makes a
> report on the tiny little part that modern Git practice has an opinion
> on, and recommends the modern alternatives.
"git config upgrade" or something would be pretty nice :)
--
D. Ben Knoble
Changing default config values (was Re: What will come after Git 2.56?)
On 24/09/2026 20:24, Junio C Hamano wrote:
Show 13 quoted lines
> Harald Nordgren <haraldnordgren@gmail.com> writes:
>
>> I have a list of breaking changes that I would like to introduce, I was hoping
>> they could be considered before 3.0 is out -- otherwise I fear I have to wait
>> another 10 years for 4.0, I would like to change the default values of these
>> config values:
>
> I do not know how long it will be before 4.0, but if you do not have
> any draft code on the list or even design presented before this
> message, it is way too late for 3.0. No, these won't be part of it.
>
> But some may not even qualify as "breaking changes", so after 3.0,
> some of them may not have to wait until 4.0 happens.
A couple of thoughts about changing the default values for config variables:
For ui related config values such as diff.algorithm, diff.colorWords, commit.verbose, merge.conflictStyle etc. where their effect is largely cosmetic and the potential negative impact of the value changing is limited, I wonder if we should be more willing to take a consequentialist approach and allow changes where the net benefit outweighs any potential downside. Currently we tend to have a deontological approach that views any negative effect on even a small number of current users as inherently bad. A consequentialist approach would allow us more flexibility to change defaults, though we'd need some way to try and gauge the relative costs and benefits.
One way we could change the default values of a set of config variables is to have a config variable, say "core.defaults", that determines the default values of the config variables we'd like to change. That would allow us to have a set of "modern defaults" that can evolve over time and can be easily enabled or disabled (a bit like "feature.experimental"). We may want to extend the concept slightly so that different values for "core.defaults" tune the defaults for different workflows; for example having a setting that implies "push.default=current" and "status.compareBranches=@{upstream} @{push}" for triangular workflows. If we take the approach suggested above, the modern defaults could be enabled by default and it would be easy for users to opt-out by setting a single config variable.
Thanks
Phillip
Re: Changing default config values (was Re: What will come after Git 2.56?)
Phillip Wood <phillip.wood123@gmail.com> writes:
Show 8 quoted lines
> A couple of thoughts about changing the default values for config variables:
>
> For ui related config values such as diff.algorithm, diff.colorWords,
> commit.verbose, merge.conflictStyle etc. where their effect is largely
> cosmetic and the potential negative impact of the value changing is
> limited, I wonder if we should be more willing to take a
> consequentialist approach and allow changes where the net benefit
> outweighs any potential downside.
I think we are already doing that (We've already changed the default merge strategy at least twice, for example), but the thing is, "net benefit" and "potential downside" are both mere speculations until you actually release such a change and wait for months to see distros deliver the change to their users.
> One way we could change the default values of a set of config variables
> is to have a config variable, say "core.defaults", that determines the
> default values of the config variables we'd like to change.
You'd need a way to poll the value of core.defaults to see the population distribution to see how beneficial the proposed update is, but then wouldn't it be easier to measure on the target configuration itself? How big a population cares enough to bother setting diff.algorithm to value X? Multiply it by 3 and you may get a rough approximation of how much of your entire population would love to live in a hypothetical world where algorithm X were the default.
Re: Changing default config values (was Re: What will come after Git 2.56?)
On Sun, Sep 27, 2026 at 02:48:31PM +0100, Phillip Wood wrote:
Show 11 quoted lines
> One way we could change the default values of a set of config variables is
> to have a config variable, say "core.defaults", that determines the default
> values of the config variables we'd like to change. That would allow us to
> have a set of "modern defaults" that can evolve over time and can be easily
> enabled or disabled (a bit like "feature.experimental"). We may want to
> extend the concept slightly so that different values for "core.defaults"
> tune the defaults for different workflows; for example having a setting that
> implies "push.default=current" and "status.compareBranches=@{upstream}
> @{push}" for triangular workflows. If we take the approach suggested above,
> the modern defaults could be enabled by default and it would be easy for
> users to opt-out by setting a single config variable.I dunno. There can be some convenience in setting foo.bar that covers a bunch of other related config options. And I'd have no objection to feature.triangular or something that changes the fallback defaults for a few relevant options (which could of course still be individually overridden).
But I'm not sure what core.defaults is buying us. If I understand, you're thinking that setting core.defaults to "modern" would give new values for a bunch of defaults. But why wouldn't we just switch the defaults? I can think of two reasons:
1. It might break scripts or other automated flows. But then, so would
config.defaults=modern (or using the individual config options
themselves). 2. It might anger old-timers who like the current defaults. But why
not just switch the defaults, and let the old-timers use the
existing config to escape-hatch back? If there's not consensus over
the defaults, _somebody_ is going to be annoyed by whatever we
pick. It's probably reasonable to pick the one that annoys the fewest
people, though I think we instead tend to go with status quo
inertia. Which, to be fair, is not entirely unreasonable simply
because we don't actually _know_ what will annoy the fewest people.
So changing nothing is often a safe guess.-Peff