{"thread":{"id":"58574","subject":"Idea: Git Bundle V3 capability @HEAD=ref/heads/","startedAt":"2022-10-06T15:55:58Z","lastAt":"2022-10-07T09:02:15Z","messageCount":3,"participants":["Philip Oakley","Junio C Hamano","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"464300","messageId":"037901f1-1649-1485-a853-9783b9d43b31@iee.email","threadId":"58574","inReplyTo":"8d88ba68-4585-634b-1fe0-61c3465fa682@iee.email","subject":"Idea: Git Bundle V3 capability @HEAD=ref/heads/","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2022-10-06T15:55:49Z","receivedAt":"2022-10-06T15:55:58Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"In brian's recent work on V3 bundles [1, et al] I spotted a potential\nidea for resolving the long standing problem that the bundle code may\nneed to guess at which ref HEAD was pointed [2, et al] at when there\nwere two branches that pointed at the same HEAD oid.\n\nThe basic idea is to utilise the new 'capabilities' field to pass the\nparticular ref that is HEAD using a 'HEAD' capability\ni.e. sending the capability    @HEAD=ref/heads/\n\nIt's inclusion in the header wouldn't change the pack in any way, and\nwould resolve the guessing problem.\n\nIt would be optional for those that don't want to explictly export the\nHEAD ref's name, and could be also protected by requiring that HEAD is\nlisted in the pack, and maybe that the ref it points to is also\nincluded, and maybe further that there is an alternate ambigous ref listed.\n\nThe idea of the HEAD capability could also be extended to the transport\nlayer, as well as this bundle sneaker-net layer.\n\nAre there reasons why it couldn't work before I put it on my list of ideas?\n\nPhilip\n\n[1] see\nhttps://lore.kernel.org/git/20200726195424.626969-32-sandals@crustytoothpaste.net/\n[PATCH v4 31/39] bundle: add new version for use with SHA-256\n\n[2] https://lore.kernel.org/git/20130906155204.GE12966@inner.h.apk.li/\n\n"},{"id":"464318","messageId":"xmqq7d1clrjh.fsf@gitster.g","threadId":"58574","inReplyTo":"037901f1-1649-1485-a853-9783b9d43b31@iee.email","subject":"Re: Idea: Git Bundle V3 capability @HEAD=ref/heads/","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-06T18:45:38Z","receivedAt":"2022-10-06T18:45:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> In brian's recent work on V3 bundles [1, et al] I spotted a potential\n> idea for resolving the long standing problem that the bundle code may\n> need to guess at which ref HEAD was pointed [2, et al] at when there\n> were two branches that pointed at the same HEAD oid.\n>\n> The basic idea is to utilise the new 'capabilities' field to pass the\n> particular ref that is HEAD using a 'HEAD' capability\n> i.e. sending the capability    @HEAD=ref/heads/\n\nWhatever you do, I think it should model what the protocol between\n\"git fetch\" and \"git upload-pack\" use to convey where the symbolic\nrefs point at.\n"},{"id":"464350","messageId":"Yz/rAHYi8JKylHqy@tapette.crustytoothpaste.net","threadId":"58574","inReplyTo":"037901f1-1649-1485-a853-9783b9d43b31@iee.email","subject":"Re: Idea: Git Bundle V3 capability @HEAD=ref/heads/","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-10-07T09:02:07Z","receivedAt":"2022-10-07T09:02:15Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-10-06 at 15:55:49, Philip Oakley wrote:\n> In brian's recent work on V3 bundles [1, et al] I spotted a potential\n> idea for resolving the long standing problem that the bundle code may\n> need to guess at which ref HEAD was pointed [2, et al] at when there\n> were two branches that pointed at the same HEAD oid.\n> \n> The basic idea is to utilise the new 'capabilities' field to pass the\n> particular ref that is HEAD using a 'HEAD' capability\n> i.e. sending the capability    @HEAD=ref/heads/\n> \n> It's inclusion in the header wouldn't change the pack in any way, and\n> would resolve the guessing problem.\n> \n> It would be optional for those that don't want to explictly export the\n> HEAD ref's name, and could be also protected by requiring that HEAD is\n> listed in the pack, and maybe that the ref it points to is also\n> included, and maybe further that there is an alternate ambigous ref listed.\n> \n> The idea of the HEAD capability could also be extended to the transport\n> layer, as well as this bundle sneaker-net layer.\n> \n> Are there reasons why it couldn't work before I put it on my list of ideas?\n\nI think this is a great idea. I might suggest\n\"symref=HEAD:refs/heads/\" simply because it allows us to specify\nmore than one symref if we feel like it in the future, but otherwise I\nhave no objections.\n\nI'm glad someone's finding my v3 bundle work more generally useful.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"}]}