# Idea: Git Bundle V3 capability @HEAD=ref/heads/ 3 messages from 2022-10-06 to 2022-10-07. Participants: Philip Oakley, Junio C Hamano, brian m. carlson. Thread: https://gitlist.dev/t/58574 ## Philip Oakley, 2022-10-06 15:55 Subject: Idea: Git Bundle V3 capability @HEAD=ref/heads/ Message-ID: <037901f1-1649-1485-a853-9783b9d43b31@iee.email> URL: https://gitlist.dev/e/037901f1-1649-1485-a853-9783b9d43b31%40iee.email In-Reply-To: <8d88ba68-4585-634b-1fe0-61c3465fa682@iee.email> ``` 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/ 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/ ``` ## Junio C Hamano, 2022-10-06 18:45 Subject: Re: Idea: Git Bundle V3 capability @HEAD=ref/heads/ Message-ID: URL: https://gitlist.dev/e/xmqq7d1clrjh.fsf%40gitster.g In-Reply-To: <037901f1-1649-1485-a853-9783b9d43b31@iee.email> ``` Philip Oakley 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/ 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. ``` ## brian m. carlson, 2022-10-07 09:02 Subject: Re: Idea: Git Bundle V3 capability @HEAD=ref/heads/ Message-ID: URL: https://gitlist.dev/e/Yz%2FrAHYi8JKylHqy%40tapette.crustytoothpaste.net In-Reply-To: <037901f1-1649-1485-a853-9783b9d43b31@iee.email> ``` 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/ > > 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/" 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 ```