Re: When should we release Git 3.0?

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 1, 2025, 22:42 UTC
Message-ID: <aN2uRCbajBhZT08V@fruit.crustytoothpaste.net>
In-Reply-To: <xmqqecrm1hs1.fsf@gitster.g>

On 2025-10-01 at 20:36:14, Junio C Hamano wrote:

Show 5 quoted lines

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

Show 11 quoted lines

> 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