Idea: Git Bundle V3 capability @HEAD=ref/heads/<name>

Idea: Git Bundle V3 capability @HEAD=ref/heads/<name>

[Philip Oakley]

In brian's recent work on V3 bundles [1, et al] I spotted a potential
idea for resolving the long standing problem that the bundle code may
need to guess at which ref HEAD was pointed [2, et al] at when there
were two branches that pointed at the same HEAD oid.

The basic idea is to utilise the new 'capabilities' field to pass the
particular ref that is HEAD using a 'HEAD' capability
i.e. sending the capability    @HEAD=ref/heads/<name>

It's inclusion in the header wouldn't change the pack in any way, and
would resolve the guessing problem.

It would be optional for those that don't want to explictly export the
HEAD ref's name, and could be also protected by requiring that HEAD is
listed in the pack, and maybe that the ref it points to is also
included, and maybe further that there is an alternate ambigous ref listed.

The idea of the HEAD capability could also be extended to the transport
layer, as well as this bundle sneaker-net layer.

Are there reasons why it couldn't work before I put it on my list of ideas?

Philip

[1] see
https://lore.kernel.org/git/20200726195424.626969-32-sandals@crustytoothpaste.net/
[PATCH v4 31/39] bundle: add new version for use with SHA-256

[2] https://lore.kernel.org/git/20130906155204.GE12966@inner.h.apk.li/

Re: Idea: Git Bundle V3 capability @HEAD=ref/heads/<name>

[Junio C Hamano]

Philip Oakley <philipoakley@iee.email> writes:

> In brian's recent work on V3 bundles [1, et al] I spotted a potential
> idea for resolving the long standing problem that the bundle code may
> need to guess at which ref HEAD was pointed [2, et al] at when there
> were two branches that pointed at the same HEAD oid.
>
> The basic idea is to utilise the new 'capabilities' field to pass the
> particular ref that is HEAD using a 'HEAD' capability
> i.e. sending the capability    @HEAD=ref/heads/<name>

Whatever you do, I think it should model what the protocol between
"git fetch" and "git upload-pack" use to convey where the symbolic
refs point at.

Re: Idea: Git Bundle V3 capability @HEAD=ref/heads/<name>

[brian m. carlson]

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

On 2022-10-06 at 15:55:49, Philip Oakley wrote:
> In brian's recent work on V3 bundles [1, et al] I spotted a potential
> idea for resolving the long standing problem that the bundle code may
> need to guess at which ref HEAD was pointed [2, et al] at when there
> were two branches that pointed at the same HEAD oid.
> 
> The basic idea is to utilise the new 'capabilities' field to pass the
> particular ref that is HEAD using a 'HEAD' capability
> i.e. sending the capability    @HEAD=ref/heads/<name>
> 
> It's inclusion in the header wouldn't change the pack in any way, and
> would resolve the guessing problem.
> 
> It would be optional for those that don't want to explictly export the
> HEAD ref's name, and could be also protected by requiring that HEAD is
> listed in the pack, and maybe that the ref it points to is also
> included, and maybe further that there is an alternate ambigous ref listed.
> 
> The idea of the HEAD capability could also be extended to the transport
> layer, as well as this bundle sneaker-net layer.
> 
> Are there reasons why it couldn't work before I put it on my list of ideas?

I think this is a great idea.  I might suggest
"symref=HEAD:refs/heads/<name>" simply because it allows us to specify
more than one symref if we feel like it in the future, but otherwise I
have no objections.

I'm glad someone's finding my v3 bundle work more generally useful.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

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