When should we release Git 3.0?

When should we release Git 3.0?

[brian m. carlson]

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

There's been discussion at the Contributor Summit about when we should
release Git 3.0.  The original plan that was discussed was to release in
about a year, which is about 4 releases away.

Almost all of the functionality that we had wanted in Git 3.0 has been
implemented.  The two major things we may want to consider as blockers
for Git 3.0 are the following:

* The SHA-256 interoperability work is not done yet.  My estimate of
  this work is 200–400 patches, of which about 100 are done.  If the
  original schedule is maintained, this would require writing up to 75
  patches and sending in 100 patches per cycle, which is unrealistic
  without additional contributors.
* Some forges and other projects do not yet have full SHA-256 support.
  It's my understanding that all of the major forges are undertaking or
  have undertaken this work and are at various levels of completion, but
  it's not clear that other projects have appropriate support.

We may also wish to stick to a stricter timeframe for this release
regardless and make four releases from now or the next release a year
away Git 3.0 regardless of whether those items above are completed.

Discussions at the Contributor Summit did mention the advantage of
having a hard deadline would be that it would make projects and forges
spend the time to implement SHA-256 support if they're lacking it.

I personally do not want the interoperability work to be a blocker.  I
haven't really heard other commitments of contributors who want to work
on it and I don't really want to have to run full tilt trying to get it
out.  However, some other people may feel differently, in which I case I
encourage their participation in the project.

What do others think about this?
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

Re: When should we release Git 3.0?

[Luca Milanesio]

> On 1 Oct 2025, at 00:07, brian m. carlson <sandals@crustytoothpaste.net> wrote:
> 
> There's been discussion at the Contributor Summit about when we should
> release Git 3.0.  The original plan that was discussed was to release in
> about a year, which is about 4 releases away.
> 
> Almost all of the functionality that we had wanted in Git 3.0 has been
> implemented.  The two major things we may want to consider as blockers
> for Git 3.0 are the following:
> 
> * The SHA-256 interoperability work is not done yet.  My estimate of
>  this work is 200–400 patches, of which about 100 are done.  If the
>  original schedule is maintained, this would require writing up to 75
>  patches and sending in 100 patches per cycle, which is unrealistic
>  without additional contributors.
> * Some forges and other projects do not yet have full SHA-256 support.
>  It's my understanding that all of the major forges are undertaking or
>  have undertaken this work and are at various levels of completion, but
>  it's not clear that other projects have appropriate support.
> 
> We may also wish to stick to a stricter timeframe for this release
> regardless and make four releases from now or the next release a year
> away Git 3.0 regardless of whether those items above are completed.

I apologise to not have participated to the Contributor Summit, I just joined the Git Mini-Summit in Amsterdam and we discussed briefly Gerrit 3.0 over dinner, but not with such a detail.
Do you have the notes or recording of the discussion?

I am worried that if we rush into Git 3.0 with breaking changes that would make other “forges” (e.g. JGit) incompatible, we would be in a difficult situation with the other Git ecosystem that isn’t based on the C-Git implementation.

> Discussions at the Contributor Summit did mention the advantage of
> having a hard deadline would be that it would make projects and forges
> spend the time to implement SHA-256 support if they're lacking it.

Happy to spend more time on it, I believe Nasser and Martin from the JGit project attended in-person yesterday.
Any commitment from your side? Do you have budget from your $DAY_JOB?

> I personally do not want the interoperability work to be a blocker.  I
> haven't really heard other commitments of contributors who want to work
> on it and I don't really want to have to run full tilt trying to get it
> out.  However, some other people may feel differently, in which I case I
> encourage their participation in the project.

Sure, happy to participate.

Luca.

Re: When should we release Git 3.0?

[Taylor Blau]

On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:
> I am worried that if we rush into Git 3.0 with breaking changes that
> would make other “forges” (e.g. JGit) incompatible, we would be in a
> difficult situation with the other Git ecosystem that isn’t based on
> the C-Git implementation.

That's a good point. I am not familiar enough with JGit (or really any
non-standard Git implementations) to know where SHA-256 support is in
those respective implementations.

But regardless of whether we're talking about a forge that is based on
git.git or some other implementation, there is very likely lots of other
work to be done to support SHA-256 outside of flipping the hash function
within Git.

(I'm thinking here about database migrations for columns that may store
40-character SHA-1 hashes, for example, which can take a potentially
significant amount of time to migrate depending on the size of the
database, etc.)

So my feeling here is that we should take into account not just the
readiness of the underlying Git implementation used by hosting providers
in the Git ecosystem, but also the readiness of the hosting providers
themselves to do the work necessary to facilitate that transition
outside of their Git implementation.

Thanks,
Taylor

RE: When should we release Git 3.0?

[rsbecker]

On October 1, 2025 12:05 PM, Taylor Blau wrote:
>On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:
>> I am worried that if we rush into Git 3.0 with breaking changes that
>> would make other “forges” (e.g. JGit) incompatible, we would be in a
>> difficult situation with the other Git ecosystem that isn’t based on
>> the C-Git implementation.
>
>That's a good point. I am not familiar enough with JGit (or really any non-standard
>Git implementations) to know where SHA-256 support is in those respective
>implementations.

AFAIK, JGit still depends on some core git functions, including gc. It also depends on
LFS for those functions. Interop it fairly important in that space.

>But regardless of whether we're talking about a forge that is based on git.git or
>some other implementation, there is very likely lots of other work to be done to
>support SHA-256 outside of flipping the hash function within Git.
>
>(I'm thinking here about database migrations for columns that may store 40-
>character SHA-1 hashes, for example, which can take a potentially significant
>amount of time to migrate depending on the size of the database, etc.)
>
>So my feeling here is that we should take into account not just the readiness of the
>underlying Git implementation used by hosting providers in the Git ecosystem, but
>also the readiness of the hosting providers themselves to do the work necessary to
>facilitate that transition outside of their Git implementation.

Regards,
Randall

Re: When should we release Git 3.0?

[Taylor Blau]

On Wed, Oct 01, 2025 at 03:31:54PM -0400, rsbecker@nexbridge.com wrote:
> On October 1, 2025 12:05 PM, Taylor Blau wrote:
> >On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:
> >> I am worried that if we rush into Git 3.0 with breaking changes that
> >> would make other “forges” (e.g. JGit) incompatible, we would be in a
> >> difficult situation with the other Git ecosystem that isn’t based on
> >> the C-Git implementation.
> >
> >That's a good point. I am not familiar enough with JGit (or really any non-standard
> >Git implementations) to know where SHA-256 support is in those respective
> >implementations.
>
> AFAIK, JGit still depends on some core git functions, including gc. It
> also depends on LFS for those functions. Interop it fairly important
> in that space.

What are "core git functions" here? I'm not at all familiar with JGit,
but my understanding is that it doesn't use the Git binary directly
whatsoever, so I am not sure how the presence of interop support or not
would affect JGit or LFS.

Thanks,
Taylor

RE: When should we release Git 3.0?

[rsbecker]

On October 8, 2025 5:45 PM, Taylor Blau wrote:
>On Wed, Oct 01, 2025 at 03:31:54PM -0400, rsbecker@nexbridge.com wrote:
>> On October 1, 2025 12:05 PM, Taylor Blau wrote:
>> >On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:
>> >> I am worried that if we rush into Git 3.0 with breaking changes
>> >> that would make other “forges” (e.g. JGit) incompatible, we would
>> >> be in a difficult situation with the other Git ecosystem that isn’t
>> >> based on the C-Git implementation.
>> >
>> >That's a good point. I am not familiar enough with JGit (or really
>> >any non-standard Git implementations) to know where SHA-256 support
>> >is in those respective implementations.
>>
>> AFAIK, JGit still depends on some core git functions, including gc. It
>> also depends on LFS for those functions. Interop it fairly important
>> in that space.
>
>What are "core git functions" here? I'm not at all familiar with JGit, but my
>understanding is that it doesn't use the Git binary directly whatsoever, so I am not
>sure how the presence of interop support or not would affect JGit or LFS.

I tried doing a JGit gc. It delegates to git. There are other functions.

Re: When should we release Git 3.0?

[Patrick Steinhardt]

On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:
> On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:
> > I am worried that if we rush into Git 3.0 with breaking changes that
> > would make other “forges” (e.g. JGit) incompatible, we would be in a
> > difficult situation with the other Git ecosystem that isn’t based on
> > the C-Git implementation.
> 
> That's a good point. I am not familiar enough with JGit (or really any
> non-standard Git implementations) to know where SHA-256 support is in
> those respective implementations.
> 
> But regardless of whether we're talking about a forge that is based on
> git.git or some other implementation, there is very likely lots of other
> work to be done to support SHA-256 outside of flipping the hash function
> within Git.
> 
> (I'm thinking here about database migrations for columns that may store
> 40-character SHA-1 hashes, for example, which can take a potentially
> significant amount of time to migrate depending on the size of the
> database, etc.)
> 
> So my feeling here is that we should take into account not just the
> readiness of the underlying Git implementation used by hosting providers
> in the Git ecosystem, but also the readiness of the hosting providers
> themselves to do the work necessary to facilitate that transition
> outside of their Git implementation.

We definitely should take into account the readiness. But what I think
we'll need is a roadmap from impacted Git implementations and hosting
providers so that we can answer the question when they plan to have
SHA256 support ready.

Without such a roadmap it's basically impossible for us to set up any
realistic date. In that case, we only have one of two options:

  - We just wait until eventually everyone has SHA256 support. This has
    the effect that there is no pressure on anybody, and thus it is more
    likely than not that it'll just never happen.

  - We set a strict, "uninformed" deadline that may be too ambitious and
    unrealistic.

Once we have roadmaps, we should set a strict deadline that takes them
into account. Any hosting provider or implementation of Git that doesn't
provide a roadmap will not be taken into account in our planning.

We should of course actively reach out to the projects that we're aware
of so that they have a chance to provide such a roadmap in the first
place.

Patrick

Re: When should we release Git 3.0?

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> Once we have roadmaps, we should set a strict deadline that takes them
> into account. Any hosting provider or implementation of Git that doesn't
> provide a roadmap will not be taken into account in our planning.

Works fine as long as we assume everybody that matters will
eventually want to move away from SHA-1.

 - If a stakeholder gives a roadmap that has no SHA-256 in their
   future, in other words, if they are content to serve only the
   SHA-1 projects, what's the impact to them?  We are not dropping
   the support for SHA-1 in the sense that if you clone from an
   existing SHA-1 repository you'll get an SHA-1 repository and you
   can push and fetch between them just fine, so presumably that is
   fine as well.

 - If a stakeholder gives a roadmap with SHA-256 so far into the
   future that we cannot wait, what's the impact to them?  Their
   customers that want SHA-256 earlier than they can supply could
   move to other hosting or implementation, but not really.  Both
   hosting providers and Git implementations have components that
   are move than Git that are hard to migrate, like issue trackers,
   CI services, workflow tools, etc., that make their customers
   captive audience [*].

 - If a stakeholder has a roadmap with SHA-256 in line with our
   timeframe, do we still need to assess the impact to them, or as
   long as we and they work hard to stick to the plan, we all will
   be happy?

> We should of course actively reach out to the projects that we're aware
> of so that they have a chance to provide such a roadmap in the first
> place.


[Footnote]

 * Issue trackers and review logs that are federated, possibly using
   Git database for storage and transfer, may allow projects and
   users to freely roam across hosting sites, but there is no strong
   incentive for the hosting sites to fund such an effort X-<.

Re: When should we release Git 3.0?

[Michal Suchánek]

On Thu, Oct 02, 2025 at 08:32:38AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > Once we have roadmaps, we should set a strict deadline that takes them
> > into account. Any hosting provider or implementation of Git that doesn't
> > provide a roadmap will not be taken into account in our planning.
> 
> Works fine as long as we assume everybody that matters will
> eventually want to move away from SHA-1.
> 
>  - If a stakeholder gives a roadmap that has no SHA-256 in their
>    future, in other words, if they are content to serve only the
>    SHA-1 projects, what's the impact to them?  We are not dropping
>    the support for SHA-1 in the sense that if you clone from an
>    existing SHA-1 repository you'll get an SHA-1 repository and you
>    can push and fetch between them just fine, so presumably that is
>    fine as well.
> 
>  - If a stakeholder gives a roadmap with SHA-256 so far into the
>    future that we cannot wait, what's the impact to them?  Their
>    customers that want SHA-256 earlier than they can supply could
>    move to other hosting or implementation, but not really.  Both

I suppose that's already the case to some extent. git does support
sha256, some forges do as well, and some people want it to the point
that they install such forge, and create the sha256 repositories
although it is not the default.

There is some tradeoff here. When it's nice to have but not required
people will use it when convenient. When it's really required people
will use even an obscure implementation to get the requested feature.

>    hosting providers and Git implementations have components that
>    are move than Git that are hard to migrate, like issue trackers,
>    CI services, workflow tools, etc., that make their customers
>    captive audience [*].
> 
>  - If a stakeholder has a roadmap with SHA-256 in line with our
>    timeframe, do we still need to assess the impact to them, or as
>    long as we and they work hard to stick to the plan, we all will
>    be happy?
> 
> > We should of course actively reach out to the projects that we're aware
> > of so that they have a chance to provide such a roadmap in the first
> > place.
> 
> 
> [Footnote]
> 
>  * Issue trackers and review logs that are federated, possibly using
>    Git database for storage and transfer, may allow projects and
>    users to freely roam across hosting sites, but there is no strong
>    incentive for the hosting sites to fund such an effort X-<.

Many forges provide migration options for importing data from other
forges for which there is incentive, with various level of completeness
and reliability. Another thing that contributes to lock-in is network
effect of popular forges.

Thanks

Michal

Re: When should we release Git 3.0?

[Patrick Steinhardt]

On Thu, Oct 02, 2025 at 06:10:22PM +0200, Michal Suchánek wrote:
> On Thu, Oct 02, 2025 at 08:32:38AM -0700, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> > > Once we have roadmaps, we should set a strict deadline that takes them
> > > into account. Any hosting provider or implementation of Git that doesn't
> > > provide a roadmap will not be taken into account in our planning.
> > 
> > Works fine as long as we assume everybody that matters will
> > eventually want to move away from SHA-1.
> > 
> >  - If a stakeholder gives a roadmap that has no SHA-256 in their
> >    future, in other words, if they are content to serve only the
> >    SHA-1 projects, what's the impact to them?  We are not dropping
> >    the support for SHA-1 in the sense that if you clone from an
> >    existing SHA-1 repository you'll get an SHA-1 repository and you
> >    can push and fetch between them just fine, so presumably that is
> >    fine as well.
> > 
> >  - If a stakeholder gives a roadmap with SHA-256 so far into the
> >    future that we cannot wait, what's the impact to them?  Their
> >    customers that want SHA-256 earlier than they can supply could
> >    move to other hosting or implementation, but not really.  Both
> 
> I suppose that's already the case to some extent. git does support
> sha256, some forges do as well, and some people want it to the point
> that they install such forge, and create the sha256 repositories
> although it is not the default.
> 
> There is some tradeoff here. When it's nice to have but not required
> people will use it when convenient. When it's really required people
> will use even an obscure implementation to get the requested feature.

True. In any case, I think that for now we should just wait how such
roadmaps would look like and then discuss based on the findings.

The question of course is how to get such roadmaps. The easiest way to
do it is probably to gather a list of known projects that would be
impacted and just shoot maintainers or representatives of those an
email? From the top of my head, that would include:

  - Implementations
      - libgit2
      - JGit
      - Gitoxide
      - go-git
  - Forges
      - GitHub
      - GitLab
      - Bitbucket
      - Forgejo
      - SourceHut

I probably missed some stakeholders here, so please help me fill in the
blanks.

> >    hosting providers and Git implementations have components that
> >    are move than Git that are hard to migrate, like issue trackers,
> >    CI services, workflow tools, etc., that make their customers
> >    captive audience [*].
> > 
> >  - If a stakeholder has a roadmap with SHA-256 in line with our
> >    timeframe, do we still need to assess the impact to them, or as
> >    long as we and they work hard to stick to the plan, we all will
> >    be happy?

Well, the impact in that case would be negligible, I assume, so everyone
woudl be happy. If plans change then we can of course also adapt our own
timeline a bit, at least as long as they would give us a notification
well ahead of the scheduled flag day.

Patrick

Re: When should we release Git 3.0?

[Michal Suchánek]

On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:
> On Thu, Oct 02, 2025 at 06:10:22PM +0200, Michal Suchánek wrote:
> > On Thu, Oct 02, 2025 at 08:32:38AM -0700, Junio C Hamano wrote:
> > > Patrick Steinhardt <ps@pks.im> writes:
> > > 
> > > > Once we have roadmaps, we should set a strict deadline that takes them
> > > > into account. Any hosting provider or implementation of Git that doesn't
> > > > provide a roadmap will not be taken into account in our planning.
> > > 
> > > Works fine as long as we assume everybody that matters will
> > > eventually want to move away from SHA-1.
> > > 
> > >  - If a stakeholder gives a roadmap that has no SHA-256 in their
> > >    future, in other words, if they are content to serve only the
> > >    SHA-1 projects, what's the impact to them?  We are not dropping
> > >    the support for SHA-1 in the sense that if you clone from an
> > >    existing SHA-1 repository you'll get an SHA-1 repository and you
> > >    can push and fetch between them just fine, so presumably that is
> > >    fine as well.
> > > 
> > >  - If a stakeholder gives a roadmap with SHA-256 so far into the
> > >    future that we cannot wait, what's the impact to them?  Their
> > >    customers that want SHA-256 earlier than they can supply could
> > >    move to other hosting or implementation, but not really.  Both
> > 
> > I suppose that's already the case to some extent. git does support
> > sha256, some forges do as well, and some people want it to the point
> > that they install such forge, and create the sha256 repositories
> > although it is not the default.
> > 
> > There is some tradeoff here. When it's nice to have but not required
> > people will use it when convenient. When it's really required people
> > will use even an obscure implementation to get the requested feature.
> 
> True. In any case, I think that for now we should just wait how such
> roadmaps would look like and then discuss based on the findings.
> 
> The question of course is how to get such roadmaps. The easiest way to
> do it is probably to gather a list of known projects that would be
> impacted and just shoot maintainers or representatives of those an
> email? From the top of my head, that would include:
> 
>   - Implementations
>       - libgit2
          - pygit2
>       - JGit
>       - Gitoxide
>       - go-git
>   - Forges
>       - GitHub
>       - GitLab
>       - Bitbucket
>       - Forgejo
        - Gitea
>       - SourceHut

Thanks

Michal

Re: When should we release Git 3.0?

[Patrick Steinhardt]

On Tue, Oct 07, 2025 at 12:36:47PM +0200, Michal Suchánek wrote:
> On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:
> > The question of course is how to get such roadmaps. The easiest way to
> > do it is probably to gather a list of known projects that would be
> > impacted and just shoot maintainers or representatives of those an
> > email? From the top of my head, that would include:
> > 
> >   - Implementations
> >       - libgit2
>           - pygit2
> >       - JGit
> >       - Gitoxide
> >       - go-git

pygit2 is merely a binding for libgit2, so I didn't include it in this
list. Same for other bindings like git2go or git2-rs.

> >   - Forges
> >       - GitHub
> >       - GitLab
> >       - Bitbucket
> >       - Forgejo
>         - Gitea
> >       - SourceHut

Yup, this one should be included here indeed.

Thanks!

Patrick

Re: When should we release Git 3.0?

[Michal Suchánek]

On Tue, Oct 07, 2025 at 03:21:28PM +0200, Patrick Steinhardt wrote:
> On Tue, Oct 07, 2025 at 12:36:47PM +0200, Michal Suchánek wrote:
> > On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:
> > > The question of course is how to get such roadmaps. The easiest way to
> > > do it is probably to gather a list of known projects that would be
> > > impacted and just shoot maintainers or representatives of those an
> > > email? From the top of my head, that would include:
> > > 
> > >   - Implementations
> > >       - libgit2
> >           - pygit2
> > >       - JGit
> > >       - Gitoxide
> > >       - go-git
> 
> pygit2 is merely a binding for libgit2, so I didn't include it in this
> list. Same for other bindings like git2go or git2-rs.

Unfortunately, bindings do not automatically get the features of the
library they wrap. AFAIK libgit2 has experimental sha256 support and
pygit2 has none whatsoever. Altering the bindings to include sha256
support may involve significant design work. The native API may differ
significantly from the C API.

Both API may get broken as a result. That is pygit2 and libgit2 may
never get support, and we would need libgit3/pygit3 instead, or it may
vary depending on the language.

Thanks

Michal

Re: When should we release Git 3.0?

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> On Tue, Oct 07, 2025 at 12:36:47PM +0200, Michal Suchánek wrote:
>> On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:
>> > The question of course is how to get such roadmaps. The easiest way to
>> > do it is probably to gather a list of known projects that would be
>> > impacted and just shoot maintainers or representatives of those an
>> > email? From the top of my head, that would include:
>> > 
>> >   - Implementations
>> >       - libgit2
>>           - pygit2
>> >       - JGit
>> >       - Gitoxide
>> >       - go-git
>
> pygit2 is merely a binding for libgit2, so I didn't include it in this
> list. Same for other bindings like git2go or git2-rs.

Is dulwich still alive?

>
>> >   - Forges
>> >       - GitHub
>> >       - GitLab
>> >       - Bitbucket
>> >       - Forgejo
>>         - Gitea
>> >       - SourceHut
>
> Yup, this one should be included here indeed.
>
> Thanks!
>
> Patrick

Re: When should we release Git 3.0?

[Michal Suchánek]

On Tue, Oct 07, 2025 at 10:11:24AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > On Tue, Oct 07, 2025 at 12:36:47PM +0200, Michal Suchánek wrote:
> >> On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:
> >> > The question of course is how to get such roadmaps. The easiest way to
> >> > do it is probably to gather a list of known projects that would be
> >> > impacted and just shoot maintainers or representatives of those an
> >> > email? From the top of my head, that would include:
> >> > 
> >> >   - Implementations
> >> >       - libgit2
> >>           - pygit2
> >> >       - JGit
> >> >       - Gitoxide
> >> >       - go-git
> >
> > pygit2 is merely a binding for libgit2, so I didn't include it in this
> > list. Same for other bindings like git2go or git2-rs.
> 
> Is dulwich still alive?

Interesting, did not know it exists (also abysmal SEO, not surprising).

Its web page seems unmaintained but the git repository looks alive.

Thanks

Michal

> 
> >
> >> >   - Forges
> >> >       - GitHub
> >> >       - GitLab
> >> >       - Bitbucket
> >> >       - Forgejo
> >>         - Gitea
> >> >       - SourceHut
> >
> > Yup, this one should be included here indeed.
> >
> > Thanks!
> >
> > Patrick

Re: When should we release Git 3.0?

[SZEDER Gábor]

On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:
> The question of course is how to get such roadmaps. The easiest way to
> do it is probably to gather a list of known projects that would be
> impacted and just shoot maintainers or representatives of those an
> email? From the top of my head, that would include:
> 
>   - Implementations
>       - libgit2
>       - JGit
>       - Gitoxide
>       - go-git
>   - Forges
>       - GitHub
>       - GitLab
>       - Bitbucket
>       - Forgejo
>       - SourceHut

codeberg.org

Re: When should we release Git 3.0?

[Patrick Steinhardt]

On Wed, Oct 08, 2025 at 10:44:46PM +0200, SZEDER Gábor wrote:
> On Tue, Oct 07, 2025 at 12:27:23PM +0200, Patrick Steinhardt wrote:
> > The question of course is how to get such roadmaps. The easiest way to
> > do it is probably to gather a list of known projects that would be
> > impacted and just shoot maintainers or representatives of those an
> > email? From the top of my head, that would include:
> > 
> >   - Implementations
> >       - libgit2
> >       - JGit
> >       - Gitoxide
> >       - go-git
> >   - Forges
> >       - GitHub
> >       - GitLab
> >       - Bitbucket
> >       - Forgejo
> >       - SourceHut
> 
> codeberg.org

Isn't Codeberg essentially the one driving Forgejo? They (or a
representative of them) would have been my primary contact point there.

Thanks!

Patrick

Re: When should we release Git 3.0?

[Ben Knoble]

> Le 2 oct. 2025 à 09:33, Patrick Steinhardt <ps@pks.im> a écrit :
> 
> On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:
>> 
>> 
>> So my feeling here is that we should take into account not just the
>> readiness of the underlying Git implementation used by hosting providers
>> in the Git ecosystem, but also the readiness of the hosting providers
>> themselves to do the work necessary to facilitate that transition
>> outside of their Git implementation.
> 
> We definitely should take into account the readiness. But what I think
> we'll need is a roadmap from impacted Git implementations and hosting
> providers so that we can answer the question when they plan to have
> SHA256 support ready.
> 
> Without such a roadmap it's basically impossible for us to set up any
> realistic date. In that case, we only have one of two options:
> 
>  - We just wait until eventually everyone has SHA256 support. This has
>    the effect that there is no pressure on anybody, and thus it is more
>    likely than not that it'll just never happen.
> 
>  - We set a strict, "uninformed" deadline that may be too ambitious and
>    unrealistic.

This seems like a false dichotomy to me. Of course we can forever debate options to go forward, too, so at some point we must have a decision :)

Anyway, what about establishing a strong but adjustable (“proposed”) timeline now, based on informed opinions from folks who have already provided estimates of what’s required? Then we can shop around for input on the proposed deadline while still taking into account new information. 

It also provides impetus: “sans input, we will go forward with the proposal, so let us know if you need more time” might motivate folks to firm up their own timelines and provide said input.

> Once we have roadmaps, we should set a strict deadline that takes them
> into account. Any hosting provider or implementation of Git that doesn't
> provide a roadmap will not be taken into account in our planning.

Btw, I’ve often wondered since I see representatives from GitHub/GitLab (and JGit/Gerrit to a lesser extent) often prominently identified as such: do we have folks from GitTea/SourceHut/other smaller forges around on the mailing list to weigh in? I assume we’d also like to include their input.

Re: When should we release Git 3.0?

[Patrick Steinhardt]

On Thu, Oct 02, 2025 at 12:54:13PM -0400, Ben Knoble wrote:
> 
> > Le 2 oct. 2025 à 09:33, Patrick Steinhardt <ps@pks.im> a écrit :
> > 
> > On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:
> >> 
> >> 
> >> So my feeling here is that we should take into account not just the
> >> readiness of the underlying Git implementation used by hosting providers
> >> in the Git ecosystem, but also the readiness of the hosting providers
> >> themselves to do the work necessary to facilitate that transition
> >> outside of their Git implementation.
> > 
> > We definitely should take into account the readiness. But what I think
> > we'll need is a roadmap from impacted Git implementations and hosting
> > providers so that we can answer the question when they plan to have
> > SHA256 support ready.
> > 
> > Without such a roadmap it's basically impossible for us to set up any
> > realistic date. In that case, we only have one of two options:
> > 
> >  - We just wait until eventually everyone has SHA256 support. This has
> >    the effect that there is no pressure on anybody, and thus it is more
> >    likely than not that it'll just never happen.
> > 
> >  - We set a strict, "uninformed" deadline that may be too ambitious and
> >    unrealistic.
> 
> This seems like a false dichotomy to me. Of course we can forever
> debate options to go forward, too, so at some point we must have a
> decision :)
> 
> Anyway, what about establishing a strong but adjustable (“proposed”)
> timeline now, based on informed opinions from folks who have already
> provided estimates of what’s required? Then we can shop around for
> input on the proposed deadline while still taking into account new
> information. 
> 
> It also provides impetus: “sans input, we will go forward with the
> proposal, so let us know if you need more time” might motivate folks
> to firm up their own timelines and provide said input.

Yeah, it's definitely my goal here to do exactly that: reach out to
folks and take everyone's input into account. Once we've got it, propose
a timeline.

I guess as part of that initial communication with the stakeholders we
can also mention that the current plan is to release roughly towards the
end of next year, which may help to put things into perspective.

> > Once we have roadmaps, we should set a strict deadline that takes them
> > into account. Any hosting provider or implementation of Git that doesn't
> > provide a roadmap will not be taken into account in our planning.
> 
> Btw, I’ve often wondered since I see representatives from
> GitHub/GitLab (and JGit/Gerrit to a lesser extent) often prominently
> identified as such: do we have folks from GitTea/SourceHut/other
> smaller forges around on the mailing list to weigh in? I assume we’d
> also like to include their input.

Such smaller forges should definitely be included. My plan is to gather
a list of stakeholders for now and then send an email where we Cc
maintainers of such implementations.

Patrick

RE: When should we release Git 3.0?

[rsbecker]

On October 7, 2025 6:27 AM, Patrick Steinhardt wrote:
>On Thu, Oct 02, 2025 at 12:54:13PM -0400, Ben Knoble wrote:
>>
>> > Le 2 oct. 2025 à 09:33, Patrick Steinhardt <ps@pks.im> a écrit :
>> >
>> > On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:
>> >>
>> >>
>> >> So my feeling here is that we should take into account not just the
>> >> readiness of the underlying Git implementation used by hosting
>> >> providers in the Git ecosystem, but also the readiness of the
>> >> hosting providers themselves to do the work necessary to facilitate
>> >> that transition outside of their Git implementation.
>> >
>> > We definitely should take into account the readiness. But what I
>> > think we'll need is a roadmap from impacted Git implementations and
>> > hosting providers so that we can answer the question when they plan
>> > to have
>> > SHA256 support ready.
>> >
>> > Without such a roadmap it's basically impossible for us to set up
>> > any realistic date. In that case, we only have one of two options:
>> >
>> >  - We just wait until eventually everyone has SHA256 support. This has
>> >    the effect that there is no pressure on anybody, and thus it is more
>> >    likely than not that it'll just never happen.
>> >
>> >  - We set a strict, "uninformed" deadline that may be too ambitious and
>> >    unrealistic.
>>
>> This seems like a false dichotomy to me. Of course we can forever
>> debate options to go forward, too, so at some point we must have a
>> decision :)
>>
>> Anyway, what about establishing a strong but adjustable (“proposed”)
>> timeline now, based on informed opinions from folks who have already
>> provided estimates of what’s required? Then we can shop around for
>> input on the proposed deadline while still taking into account new
>> information.
>>
>> It also provides impetus: “sans input, we will go forward with the
>> proposal, so let us know if you need more time” might motivate folks
>> to firm up their own timelines and provide said input.
>
>Yeah, it's definitely my goal here to do exactly that: reach out to folks and take
>everyone's input into account. Once we've got it, propose a timeline.

My own blocking situation is a lack of Rust. This is being discussed by the OS
vendor and I hope we get some progress soon. I do not control what "soon" is
but it is at least a year. This is HPE NonStop.

>I guess as part of that initial communication with the stakeholders we can also
>mention that the current plan is to release roughly towards the end of next year,
>which may help to put things into perspective.
>
>> > Once we have roadmaps, we should set a strict deadline that takes
>> > them into account. Any hosting provider or implementation of Git
>> > that doesn't provide a roadmap will not be taken into account in our planning.
>>
>> Btw, I’ve often wondered since I see representatives from
>> GitHub/GitLab (and JGit/Gerrit to a lesser extent) often prominently
>> identified as such: do we have folks from GitTea/SourceHut/other
>> smaller forges around on the mailing list to weigh in? I assume we’d
>> also like to include their input.
>
>Such smaller forges should definitely be included. My plan is to gather a list of
>stakeholders for now and then send an email where we Cc maintainers of such
>implementations.

My own front-end implementation has been ready for SHA-256 for 2 years and
have been (im)patiently waiting. I have a distinct separation between git version
and implementation so there is no direct dependency there. Only Rust availability
on the git built is holding my own situation back.
--Randall

Re: When should we release Git 3.0?

[Taylor Blau]

On Tue, Oct 07, 2025 at 12:27:16PM +0200, Patrick Steinhardt wrote:
> Yeah, it's definitely my goal here to do exactly that: reach out to
> folks and take everyone's input into account. Once we've got it, propose
> a timeline.
>
> I guess as part of that initial communication with the stakeholders we
> can also mention that the current plan is to release roughly towards the
> end of next year, which may help to put things into perspective.

I am not sure what our proposal would be other than max(proposed_dates),
clamped to some reasonable range that we are comfortable with so as not
to delay the transition to use SHA-256 by default too far into the
future.

I think a more interesting question is:

 - What do we do for implementations that do not have a roadmap, or
   whose roadmap is too far into the future?

 - What do we do for implementations that have a roadmap, have a date
   that is palatable to the project, but end up slipping and are unable
   to meet that date?

I generally agree that we have to draw a line in the sand *somewhere*,
but I don't think we should be so inflexible as to say "if you don't
have SHA-256 done by X date, you are out of luck". Of course, if the
amended timeline is too far beyond the initial deadline that's one case.
But if someone is a release cycle or so behind, I think it's reasonable
that the project should be flexible enough to accommodate that.

Thanks,
Taylor

Re: When should we release Git 3.0?

[Patrick Steinhardt]

On Wed, Oct 08, 2025 at 06:05:04PM -0400, Taylor Blau wrote:
> On Tue, Oct 07, 2025 at 12:27:16PM +0200, Patrick Steinhardt wrote:
> > Yeah, it's definitely my goal here to do exactly that: reach out to
> > folks and take everyone's input into account. Once we've got it, propose
> > a timeline.
> >
> > I guess as part of that initial communication with the stakeholders we
> > can also mention that the current plan is to release roughly towards the
> > end of next year, which may help to put things into perspective.
> 
> I am not sure what our proposal would be other than max(proposed_dates),
> clamped to some reasonable range that we are comfortable with so as not
> to delay the transition to use SHA-256 by default too far into the
> future.
> 
> I think a more interesting question is:
> 
>  - What do we do for implementations that do not have a roadmap, or
>    whose roadmap is too far into the future?
> 
>  - What do we do for implementations that have a roadmap, have a date
>    that is palatable to the project, but end up slipping and are unable
>    to meet that date?
> 
> I generally agree that we have to draw a line in the sand *somewhere*,
> but I don't think we should be so inflexible as to say "if you don't
> have SHA-256 done by X date, you are out of luck". Of course, if the
> amended timeline is too far beyond the initial deadline that's one case.
> But if someone is a release cycle or so behind, I think it's reasonable
> that the project should be flexible enough to accommodate that.

Yeah, if it's about a small number of releases I definitely think we
should accommodate for that. But if it's "We'll never have it" or "We'll
have it in five years" it's probably a different story.

In any case though, I'd propose to punt on those questions for now and
wait for feedback from the impacted communities first. Once we have such
feedback we can discuss in more detail.

Patrick

Re: When should we release Git 3.0?

[brian m. carlson]

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

On 2025-10-08 at 22:05:04, Taylor Blau wrote:
> I am not sure what our proposal would be other than max(proposed_dates),
> clamped to some reasonable range that we are comfortable with so as not
> to delay the transition to use SHA-256 by default too far into the
> future.
> 
> I think a more interesting question is:
> 
>  - What do we do for implementations that do not have a roadmap, or
>    whose roadmap is too far into the future?
> 
>  - What do we do for implementations that have a roadmap, have a date
>    that is palatable to the project, but end up slipping and are unable
>    to meet that date?
> 
> I generally agree that we have to draw a line in the sand *somewhere*,
> but I don't think we should be so inflexible as to say "if you don't
> have SHA-256 done by X date, you are out of luck". Of course, if the
> amended timeline is too far beyond the initial deadline that's one case.
> But if someone is a release cycle or so behind, I think it's reasonable
> that the project should be flexible enough to accommodate that.

I agree that it would be appropriate to be somewhat flexible.  My
personal view is that we should inform stakeholders relatively soon
(preferably within the next month) and expect them to promptly and
diligently undertake the necessary work to get started (maybe within
another month) and provide a rough roadmap.

If that happens, I expect most stakeholders will be done in about a year
to a year and a half, tops.  Assuming a reasonable release cycle, I
think it should be fine to give people some grace to do a release with
those changes as long as they can communicate a reasonable timeline to
us and show that they're making a reasonably diligent effort.

I also think there will be some stakeholders, probably including some
forges, that will not promptly undertake the work.  In my view, the
answer then is that we won't consider their readiness as affecting our
timeline.

There are also some implementations that I know already have SHA-256
support.  I believe libgit2 and Forgejo both have at least some
functionality there, so we may want to just give them a heads up that
they may want to polish any support they have before Git 3.0.

If we want to set a hard cap, then I'd say two years.  I know that's
what we said in 2024, but we didn't communicate it well at the time.
What I have been communicating elsewhere is that Git 3.0 is tentatively
planned for a year from now, so that may be a good initial phrasing to
set expectations, with the clarifications we've specified.  I think a
year from now would be good if all the relevant stakeholders are
finished before then (which is possible, but unlikely).
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

Re: When should we release Git 3.0?

[Taylor Blau]

On Thu, Oct 02, 2025 at 03:31:11PM +0200, Patrick Steinhardt wrote:
> On Wed, Oct 01, 2025 at 12:04:38PM -0400, Taylor Blau wrote:
> > On Wed, Oct 01, 2025 at 08:13:12AM +0100, Luca Milanesio wrote:
> > > I am worried that if we rush into Git 3.0 with breaking changes that
> > > would make other “forges” (e.g. JGit) incompatible, we would be in a
> > > difficult situation with the other Git ecosystem that isn’t based on
> > > the C-Git implementation.
> >
> > That's a good point. I am not familiar enough with JGit (or really any
> > non-standard Git implementations) to know where SHA-256 support is in
> > those respective implementations.
> >
> > But regardless of whether we're talking about a forge that is based on
> > git.git or some other implementation, there is very likely lots of other
> > work to be done to support SHA-256 outside of flipping the hash function
> > within Git.
> >
> > (I'm thinking here about database migrations for columns that may store
> > 40-character SHA-1 hashes, for example, which can take a potentially
> > significant amount of time to migrate depending on the size of the
> > database, etc.)
> >
> > So my feeling here is that we should take into account not just the
> > readiness of the underlying Git implementation used by hosting providers
> > in the Git ecosystem, but also the readiness of the hosting providers
> > themselves to do the work necessary to facilitate that transition
> > outside of their Git implementation.
>
> We definitely should take into account the readiness. But what I think
> we'll need is a roadmap from impacted Git implementations and hosting
> providers so that we can answer the question when they plan to have
> SHA256 support ready.
>
> Without such a roadmap it's basically impossible for us to set up any
> realistic date. In that case, we only have one of two options:
>
>   - We just wait until eventually everyone has SHA256 support. This has
>     the effect that there is no pressure on anybody, and thus it is more
>     likely than not that it'll just never happen.
>
>   - We set a strict, "uninformed" deadline that may be too ambitious and
>     unrealistic.
>
> Once we have roadmaps, we should set a strict deadline that takes them
> into account. Any hosting provider or implementation of Git that doesn't
> provide a roadmap will not be taken into account in our planning.

I would imagine that the definition of "roadmap" here is fairly
lightweight, since I imagine that some organizations may not want to
share details beyond "we will have it done by X date".

I think I generally agree with you, but I would say that while I think
the project should take a firm stance on when it will release Git 3.0, I
do not think that we should entirely disregard the readiness of
forges/implementations by making the deadline so strict.

Thanks,
Taylor

Re: When should we release Git 3.0?

[brian m. carlson]

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

On 2025-10-08 at 21:59:03, Taylor Blau wrote:
> I would imagine that the definition of "roadmap" here is fairly
> lightweight, since I imagine that some organizations may not want to
> share details beyond "we will have it done by X date".

Certainly.  I think the more details stakeholders are willing to give
us, though, the more flexible we can be.  If a forge says, "we're about
75% done, but our CI product needs another month," that's a more
compelling argument than, "well, we just need another month for
reasons," especially if their previous deadline has already slipped
(which tends to happen on software projects, as we all know).

For open source projects, of course, seeing progress is relatively easy.
Many companies may have alpha or beta programs and could share that
status with us if they don't wish to be more specific.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

Re: When should we release Git 3.0?

[brian m. carlson]

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

On 2025-10-01 at 07:13:12, Luca Milanesio wrote:
> > I personally do not want the interoperability work to be a blocker.  I
> > haven't really heard other commitments of contributors who want to work
> > on it and I don't really want to have to run full tilt trying to get it
> > out.  However, some other people may feel differently, in which I case I
> > encourage their participation in the project.
> 
> Sure, happy to participate.

Fantastic.  If you're interested, you can get the current state of the
project from the `sha256-interop` branch at
https://github.com/bk2204/git.git.  This is frequently rebased, but
mostly to squash down patches or add new features.  It is based on v7 of
Patrick Steinhardt's Rust series and will effectively require
`WITH_RUST=1` to function.

One really valuable thing that you could work on if you like is a tool
to do in-place migration of repositories to add a compatibility
algorithm, so SHA-1 repositories would have SHA-256 compatibility added
on top.  That might look like this:

* Recursively convert submodules, if any.
* Build a loose object map for any submodule commits that exist in the
  history.
* Repack all the loose objects into a pack (including using a cruft pack
  if necessary).
* Regenerate the indexes for the pack using pack index v3.

This might be a good subcommand for something like a `git hash`
command, maybe `git hash convert`.  We'd probably want to anticipate
maybe in the future having a mode that converts the main algorithm, too,
although that need not be implemented now.

You should be able to test this end-to-end with Git's repository, since
it has submodules.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

Re: When should we release Git 3.0?

[Taylor Blau]

On Tue, Sep 30, 2025 at 11:07:42PM +0000, brian m. carlson wrote:
> Almost all of the functionality that we had wanted in Git 3.0 has been
> implemented.  The two major things we may want to consider as blockers
> for Git 3.0 are the following:
>
> * The SHA-256 interoperability work is not done yet.  My estimate of
>   this work is 200–400 patches, of which about 100 are done.  If the
>   original schedule is maintained, this would require writing up to 75
>   patches and sending in 100 patches per cycle, which is unrealistic
>   without additional contributors.

I need to polish up the notes from the Contributor's Summit and share
them with the list, but my general feeling at the end of the discussion
on the SHA-256 interoperability work was that it wasn't clear whether or
not it should be a blocker for Git 3.0.

If post-3.0 repositories are using SHA-256, then either their post-Git
3.0 clients will also use SHA-256, or the pre-3.0 clients (without
interop support) will be unable to interact with them. I don't think
there would be any reason to have a interop-capable client use a SHA-256
repository in SHA-1 mode.

On the other side of the coin, if a repository is still using SHA-1,
then both pre-3.0 and post-3.0 clients will be able to interact with it
without interop support.

But you have thought about the interop work far more than I (or anybody
else) has, so I am very likely missing some obvious use-case here.

> * Some forges and other projects do not yet have full SHA-256 support.
>   It's my understanding that all of the major forges are undertaking or
>   have undertaken this work and are at various levels of completion, but
>   it's not clear that other projects have appropriate support.
>
> We may also wish to stick to a stricter timeframe for this release
> regardless and make four releases from now or the next release a year
> away Git 3.0 regardless of whether those items above are completed.
>
> Discussions at the Contributor Summit did mention the advantage of
> having a hard deadline would be that it would make projects and forges
> spend the time to implement SHA-256 support if they're lacking it.

My feeling on this portion of the discussion was that we should take
into account the readiness of the ecosystem as a whole in deciding when
to release Git 3.0.

I agree that not having a deadline can lead to forges delaying the work
necessary to support SHA-256 repositories, so I agree that we shouldn't
push it off into the future indefinitely.

On the other side of the coin, I don't think we should rush Git 3.0 out
the door before the ecosystem is broadly ready for it. If we do that,
we're creating a worse experience for a significant portion of Git users
that use popular forges who may not have complete SHA-256 support at the
time of the release.

Thanks,
Taylor

Re: When should we release Git 3.0?

[Michal Suchánek]

Hello,

On Wed, Oct 01, 2025 at 12:01:20PM -0400, Taylor Blau wrote:
> On Tue, Sep 30, 2025 at 11:07:42PM +0000, brian m. carlson wrote:
> > Almost all of the functionality that we had wanted in Git 3.0 has been
> > implemented.  The two major things we may want to consider as blockers
> > for Git 3.0 are the following:
> >
> > * The SHA-256 interoperability work is not done yet.  My estimate of
> >   this work is 200–400 patches, of which about 100 are done.  If the
> >   original schedule is maintained, this would require writing up to 75
> >   patches and sending in 100 patches per cycle, which is unrealistic
> >   without additional contributors.

From my very limited point of view as a user the interop is the major
planned feature currently missing in git, and I do not see much point
without it. Then again I do not know how useful it will be in practice.

> I need to polish up the notes from the Contributor's Summit and share
> them with the list, but my general feeling at the end of the discussion
> on the SHA-256 interoperability work was that it wasn't clear whether or
> not it should be a blocker for Git 3.0.
> 
> If post-3.0 repositories are using SHA-256, then either their post-Git
> 3.0 clients will also use SHA-256, or the pre-3.0 clients (without
> interop support) will be unable to interact with them. I don't think
> there would be any reason to have a interop-capable client use a SHA-256
> repository in SHA-1 mode.

Flipping the default to sha256 would clearly break some things. I can
use sha256 repositories in gitea today (no interop whatsoever) but
github rejects them.

Then again cloning a repository uses the correct hash which means if I
create the repository on the forge and clone it there is no problem
whatsoever regardless of hash used. Whill that break as well?

Thanks

Michal

Re: When should we release Git 3.0?

[brian m. carlson]

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

On 2025-10-01 at 16:20:05, Michal Suchánek wrote:
> From my very limited point of view as a user the interop is the major
> planned feature currently missing in git, and I do not see much point
> without it. Then again I do not know how useful it will be in practice.

It is the major planned feature which was missing.

The primary use cases are converting repositories and working with
repositories using a different algorithm.  The latter might be useful if
you're using a SHA-256 repository that someone else has created but your
tooling cannot handle longer object IDs or otherwise has some limitation
of that sort.

If you are happy working with SHA-1 repositories in SHA-1 and SHA-256
repositories in SHA-256, then you don't need the interoperability work.
SHA-256 repositories have been supported in a compatible way since 2.29
or 2.30.

> Then again cloning a repository uses the correct hash which means if I
> create the repository on the forge and clone it there is no problem
> whatsoever regardless of hash used. Whill that break as well?

Cloning a repository always uses the existing algorithm.  The default
would change to create _new_ repositories created with `git init` with
SHA-256 (although you could change the settings to use SHA-1 instead),
but it wouldn't affect existing repositories.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

Re: When should we release Git 3.0?

[Michal Suchánek]

On Wed, Oct 01, 2025 at 10:16:40PM +0000, brian m. carlson wrote:
> On 2025-10-01 at 16:20:05, Michal Suchánek wrote:
> > From my very limited point of view as a user the interop is the major
> > planned feature currently missing in git, and I do not see much point
> > without it. Then again I do not know how useful it will be in practice.
> 
> It is the major planned feature which was missing.
> 
> The primary use cases are converting repositories and working with
> repositories using a different algorithm.  The latter might be useful if
> you're using a SHA-256 repository that someone else has created but your
> tooling cannot handle longer object IDs or otherwise has some limitation
> of that sort.

It cannot, and the compat will not help with that because it's using
pygit which will not get that compat code. Presumably some baroque
scheme that re-exports the repository as sha1 might be possible but it's
not clear if that would be practical.

Another problem people are comlaining about is that with a mix of sha1
and sha256 repositories submodules and subtrees don't work. For that the
compat might actually help but the repository will then be
unintelligible to tooling that does not have compat code, which probably
includes all forges at this point.  Again, some baroque scheme that
re-exports the repository in the other hash using the compat code might
help but it's not clear if that would be practical.

Thanks

Michal

Re: When should we release Git 3.0?

[Michal Suchánek]

On Thu, Oct 02, 2025 at 02:13:09PM +0200, Michal Suchánek wrote:
> On Wed, Oct 01, 2025 at 10:16:40PM +0000, brian m. carlson wrote:
> > On 2025-10-01 at 16:20:05, Michal Suchánek wrote:
> > > From my very limited point of view as a user the interop is the major
> > > planned feature currently missing in git, and I do not see much point
> > > without it. Then again I do not know how useful it will be in practice.
> > 
> > It is the major planned feature which was missing.
> > 
> > The primary use cases are converting repositories and working with
> > repositories using a different algorithm.  The latter might be useful if
> > you're using a SHA-256 repository that someone else has created but your
> > tooling cannot handle longer object IDs or otherwise has some limitation
> > of that sort.
> 
> It cannot, and the compat will not help with that because it's using
> pygit which will not get that compat code. Presumably some baroque
> scheme that re-exports the repository as sha1 might be possible but it's
> not clear if that would be practical.
> 
> Another problem people are comlaining about is that with a mix of sha1
> and sha256 repositories submodules and subtrees don't work. For that the
> compat might actually help but the repository will then be
> unintelligible to tooling that does not have compat code, which probably
> includes all forges at this point.  Again, some baroque scheme that
> re-exports the repository in the other hash using the compat code might
> help but it's not clear if that would be practical.

I would assume the compat client could upload the same repository to
both sha256 forge repository and sha1 forge repository. With some
scripting it's possible to publish twice making both hashes available.
People that have a compat-capable client then would see the repositories
as identical again on their end.

Not usable in every situation but for cases when mirroring is already
done anyway plugging this in sounds fairly straightforward.

Thanks

Michal

Re: When should we release Git 3.0?

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> On Tue, Sep 30, 2025 at 11:07:42PM +0000, brian m. carlson wrote:
>> Almost all of the functionality that we had wanted in Git 3.0 has been
>> implemented.  The two major things we may want to consider as blockers
>> for Git 3.0 are the following:
>>
>> * The SHA-256 interoperability work is not done yet.  My estimate of
>>   this work is 200–400 patches, of which about 100 are done.  If the
>>   original schedule is maintained, this would require writing up to 75
>>   patches and sending in 100 patches per cycle, which is unrealistic
>>   without additional contributors.
>
> I need to polish up the notes from the Contributor's Summit and share
> them with the list, but my general feeling at the end of the discussion
> on the SHA-256 interoperability work was that it wasn't clear whether or
> not it should be a blocker for Git 3.0.
>
> If post-3.0 repositories are using SHA-256, then either their post-Git
> 3.0 clients will also use SHA-256, or the pre-3.0 clients (without
> interop support) will be unable to interact with them. I don't think
> there would be any reason to have a interop-capable client use a SHA-256
> repository in SHA-1 mode.

What is the recommended workflow if you have unpublished work,
written back in your private SHA-1 clone of a project, meant to be
submit someday to your project, that used to use SHA-1 but has
migrated to SHA-256?  Convert locally your repository to SHA-256
primary with SHA-1 compat and then push to them?

Presumably the server side _has_ already done most of the conversion
work so, provided if (and this is a huge if) we assume that the
conversion done on the server side is trustable, we should be able
to _clone_ from the server in SHA-256 primary SHA-1 compat mode, and
push your unpublished changes from your SHA-1 private repository
into this clone using SHA-1 protocol (i.e. no conversion to the
original repository)?  And upon accepting such a push, the receiving
repository (which is still a local clone of the project, but the one
you recently made and is aware of SHA-256 world) would now have your
unpublished work in SHA-256 (with SHA-1 compat) objects and everybody
is happy?

>> We may also wish to stick to a stricter timeframe for this release
>> regardless and make four releases from now or the next release a year
>> away Git 3.0 regardless of whether those items above are completed.
>>
>> Discussions at the Contributor Summit did mention the advantage of
>> having a hard deadline would be that it would make projects and forges
>> spend the time to implement SHA-256 support if they're lacking it.
>
> My feeling on this portion of the discussion was that we should take
> into account the readiness of the ecosystem as a whole in deciding when
> to release Git 3.0.
>
> I agree that not having a deadline can lead to forges delaying the work
> necessary to support SHA-256 repositories, so I agree that we shouldn't
> push it off into the future indefinitely.
>
> On the other side of the coin, I don't think we should rush Git 3.0 out
> the door before the ecosystem is broadly ready for it. If we do that,
> we're creating a worse experience for a significant portion of Git users
> that use popular forges who may not have complete SHA-256 support at the
> time of the release.

Yeah, I wouldn't exactly say "we'll tag when the world is ready",
but declaring 3.0 when nobody is ready would miss the opportunity to
make a big impact.

Re: When should we release Git 3.0?

[brian m. carlson]

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

On 2025-10-01 at 20:36:14, Junio C Hamano wrote:
> What is the recommended workflow if you have unpublished work,
> written back in your private SHA-1 clone of a project, meant to be
> submit someday to your project, that used to use SHA-1 but has
> migrated to SHA-256?  Convert locally your repository to SHA-256
> primary with SHA-1 compat and then push to them?

We don't have support to add an algorithm to an existing repository
(although that is a desired feature).  If that existed, you could add
SHA-256 as a compatibility algorithm to your SHA-1 repository and push,
or in any interoperability scenario, you could create a SHA-1 main
remote with SHA-256 compatibility, push your changes there, and then
push from there to the server.

The interoperability work requires that the client support the server's
main algorithm for pushes.  This is because with protocol v2, the client
gets a capability advertisement with supported algorithms and can choose
one for the operation.  With protocol v0, the server sends capabilities
as a read-only (GET) operation along with the refs and doesn't allow the
algorithm to be chosen, so it's impossible to get a ref advertisement in
anything but the main algorithm.  Since protocol v2 doesn't support
pushes, we can only push things in the server's main algorithm.

For the avoidance of doubt, I have no intention of adding support for
protocol v2 for pushes.  That would be a nice feature and it would allow
lifting that restriction, but I also have a responsibility to myself to
not explode the scope of this project more than it already has.

> Presumably the server side _has_ already done most of the conversion
> work so, provided if (and this is a huge if) we assume that the
> conversion done on the server side is trustable, we should be able
> to _clone_ from the server in SHA-256 primary SHA-1 compat mode, and
> push your unpublished changes from your SHA-1 private repository
> into this clone using SHA-1 protocol (i.e. no conversion to the
> original repository)?  And upon accepting such a push, the receiving
> repository (which is still a local clone of the project, but the one
> you recently made and is aware of SHA-256 world) would now have your
> unpublished work in SHA-256 (with SHA-1 compat) objects and everybody
> is happy?

We always use only one algorithm in the protocol except when we need to
map shallows, objects missing in a partial clone, or submodules, in
which case we offer a mapping of those objects only.  The mapping is
always otherwise done on the client side if the client supports both
algorithms.

You can create a SHA-256/SHA-1 clone from the server (right now via
initializing a SHA-256 repo, adding SHA-1 manually, and then fetching)
and _pull_ your changes from your SHA-1 repo, though.  (Pushing from
SHA-1 into a SHA-256/SHA-1 clone doesn't work as I mentioned above.) You
could then push to the SHA-256 server.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

Re: When should we release Git 3.0?

[James Frost]

 >   - Implementations
 >       - libgit2
 >          - pygit2
 >       - JGit
 >       - Gitoxide
 >       - go-git
 >   - Forges
 >       - GitHub
 >       - GitLab
 >       - Bitbucket
 >       - Forgejo
 >       - Gitea
 >       - SourceHut
     - Frontends
         - gitweb
         - cgit

Should we also consider other frontends, such as gitweb[^1] and cgit[^2]?

[^1]: https://git-scm.com/docs/gitweb
[^2]: https://git.zx2c4.com/cgit/about/

Re: When should we release Git 3.0?

[Patrick Steinhardt]

On Wed, Oct 08, 2025 at 08:06:18PM +0100, James Frost wrote:
> >   - Implementations
> >       - libgit2
> >          - pygit2
> >       - JGit
> >       - Gitoxide
> >       - go-git
> >   - Forges
> >       - GitHub
> >       - GitLab
> >       - Bitbucket
> >       - Forgejo
> >       - Gitea
> >       - SourceHut
>     - Frontends
>         - gitweb
>         - cgit
> 
> Should we also consider other frontends, such as gitweb[^1] and cgit[^2]?
> 
> [^1]: https://git-scm.com/docs/gitweb
> [^2]: https://git.zx2c4.com/cgit/about/

I very much assume that those may need to be adjusted, thanks!

Patrick