What will come after Git 2.56?

What will come after Git 2.56?

[Junio C Hamano]

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?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

Re: What will come after Git 2.56?

[Patrick Steinhardt]

On Sun, Sep 06, 2026 at 06:14:40PM +0000, brian m. carlson wrote:
> 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. :)

> >  (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?

[Emily Shaffer]

On Sun, Sep 6, 2026 at 8:19 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> 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.

> * 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.

>
> 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?

[rsbecker]

On September 6, 2026 2:15 PM, brian m. carlson wrote:
>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.

Randall

Re: What will come after Git 2.56?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On 2026-09-08 at 15:46:16, rsbecker@nexbridge.com wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]