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

2 messages from 2023-11-23 to 2023-11-27. Participants: guillaume.yziquel@mailfence.com, Jeff King.
Thread: https://gitlist.dev/t/60549

## guillaume.yziquel@mailfence.com, 2023-11-23 12:13

Subject: [BUG?] Semantics of HEAD when bare cloning non-bare repositories
Message-ID: <179a3f7b2605b295.375e54053ab898bd.31bd44aeb0344c08@hilbert>
URL: https://gitlist.dev/e/179a3f7b2605b295.375e54053ab898bd.31bd44aeb0344c08%40hilbert

```
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, 2023-11-27 21:56

Subject: Re: [BUG?] Semantics of HEAD when bare cloning non-bare repositories
Message-ID: <20231127215638.GE87495@coredump.intra.peff.net>
URL: https://gitlist.dev/e/20231127215638.GE87495%40coredump.intra.peff.net
In-Reply-To: <179a3f7b2605b295.375e54053ab898bd.31bd44aeb0344c08@hilbert>

```
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

```