{"thread":{"id":"60549","subject":"[BUG?] Semantics of HEAD when bare cloning non-bare repositories","startedAt":"2023-11-23T12:19:36Z","lastAt":"2023-11-27T21:56:40Z","messageCount":2,"participants":["guillaume.yziquel@mailfence.com","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"485064","messageId":"179a3f7b2605b295.375e54053ab898bd.31bd44aeb0344c08@hilbert","threadId":"60549","inReplyTo":null,"subject":"[BUG?] Semantics of HEAD when bare cloning non-bare repositories","fromName":"","fromEmail":"guillaume.yziquel@mailfence.com","sentAt":"2023-11-23T12:13:27Z","receivedAt":"2023-11-23T12:19:36Z","isPatch":false,"sender":{"key":"guillaume.yziquel@mailfence.com","avatar":null},"body":"Hi.\n\nObservation: When git clone --bare is used on a non-bare repo, the HEAD is put in ./refs/HEAD, and conflicts with ./HEAD in the sense that they may end up decorelated over time.\n\nSuggestion: When bare cloning on a non-bare repo, do not put the HEAD of the non-bare repo in refs/HEAD like every branch, but treat it separately: put it in ./HEAD, not ./refs/HEAD.\n\nContext: I was setting up an alternate repository for cargo crates, which requires a git repo to hold the index. So I wrote my config.json in a non-bare git repo, and \"deployed\" as a bare repo by git clone --bare. This created a ./refs/HEAD. However, the cargo crates repository I deployed (ktra) also updated the HEAD of that repo whenever I published private crates on it. So HEAD and refs/HEAD were not in sync. And, in the end, these got unsynchronised and I could not perform cargo fetch or cargo build with this alternate repo.\n\nRatonale: HEAD is just not a normal branch, semantically. It is what you have at the tip of your fingers in the shell with non-bare git repos. Treating as \"just as all other branches\" may be programatically convenient, but, in the end, it bypasses the fact that it just is not quite a normal branch. As the problem I experienced highlights. Which is why I would argue in favour of a distinguished treatment of HEADs when bare cloning a non-bare repo.\n\nBest regards,\n\nGuillaume Yziquel.\n"},{"id":"485183","messageId":"20231127215638.GE87495@coredump.intra.peff.net","threadId":"60549","inReplyTo":"179a3f7b2605b295.375e54053ab898bd.31bd44aeb0344c08@hilbert","subject":"Re: [BUG?] Semantics of HEAD when bare cloning non-bare repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-11-27T21:56:38Z","receivedAt":"2023-11-27T21:56:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 23, 2023 at 12:13:27PM +0000, guillaume.yziquel@mailfence.com wrote:\n\n> Observation: When git clone --bare is used on a non-bare repo, the\n> HEAD is put in ./refs/HEAD, and conflicts with ./HEAD in the sense\n> that they may end up decorelated over time.\n\nThat sounds like a bug, but I can't reproduce it here:\n\n  $ git init not-bare\n  $ git -C not-bare commit --allow-empty -m foo\n  $ git clone --bare not-bare bare.git\n  $ find bare.git/refs\n  bare.git/refs\n  bare.git/refs/tags\n  bare.git/refs/heads\n  $ cat bare.git/packed-refs\n  # pack-refs with: peeled fully-peeled sorted\n  db58e786007ca405e34df314479e27ddd337957a refs/heads/main\n\nAre you sure that your non-bare repository does not accidentally have a\n\"refs/HEAD\" that should not be there?\n\n> Suggestion: When bare cloning on a non-bare repo, do not put the HEAD\n> of the non-bare repo in refs/HEAD like every branch, but treat it\n> separately: put it in ./HEAD, not ./refs/HEAD.\n\nThat should be what happens already.\n\n-Peff\n"}]}