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

From: Jeff King <peff@peff.net>
Date: Nov 27, 2023, 21:56 UTC
Message-ID: <20231127215638.GE87495@coredump.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