threads / bug / 60549

[BUG?] Semantics of HEAD when bare cloning non-bare repositories

Subject: [BUG?] Semantics of HEAD when bare cloning non-bare repositories

## tl;dr

2 messages between Nov 23, 2023 and Nov 27, 2023.

replies: 1people: 2as markdown or json

guillaume.yziquel@mailfence.com· Nov 23, 2023, 12:13 UTC · lore
Hi.
Observation: 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.
Suggestion: 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.
Context: 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.
Ratonale: 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.
Best regards,
Guillaume Yziquel.
Jeff King· Nov 27, 2023, 21:56 UTC · re: guillaume.yziquel@mailfence.com · lore

Re: [BUG?] Semantics of HEAD when bare cloning non-bare repositories

On Thu, Nov 23, 2023 at 12:13:27PM +0000, guillaume.yziquel@mailfence.com wrote:
> Observation: 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.
That sounds like a bug, but I can't reproduce it here:
  $ git init not-bare
  $ git -C not-bare commit --allow-empty -m foo
  $ git clone --bare not-bare bare.git
  $ find bare.git/refs
  bare.git/refs
  bare.git/refs/tags
  bare.git/refs/heads
  $ cat bare.git/packed-refs
  # pack-refs with: peeled fully-peeled sorted
  db58e786007ca405e34df314479e27ddd337957a refs/heads/main

Are you sure that your non-bare repository does not accidentally have a "refs/HEAD" that should not be there?

> Suggestion: 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.
That should be what happens already.
-Peff

← back to recent threads