Re: Strange behaviour when pushing a commit object to remote's refs/HEAD

From: Jeff King <peff@peff.net>
Date: Jan 16, 2024, 15:00 UTC
Message-ID: <20240116150027.GB2119690@coredump.intra.peff.net>
In-Reply-To: <CAOLa=ZRfr+oEKCo8AfFSAFtS8pbDgmG_EeBSwm7GwukzVcqSrg@mail.gmail.com>

On Tue, Jan 16, 2024 at 08:24:04AM -0500, Karthik Nayak wrote:

Show 7 quoted lines

> This is one of those ambiguities, we store HEAD for remotes as
>      $GIT_DIR/refs/remotes/<remote>/HEAD
> and remote branches as
>      $GIT_DIR/refs/remotes/<remote>/<branch>
> 
> So what happens if there is a branch named HEAD? This is the problem
> you're facing...

Yeah, this is a long-standing issue. The reason we have not fixed it is that it would require a new refs/remotes layout, which implies new lookup rules (e.g., dwim_ref() will convert the name "foo" to "refs/remotes/foo/HEAD", but would need to be taught about the new layout). Likewise, a new layout should probably store per-remote tags (rather than splatting them into the main refs/tags/) along with new dwim_ref() rules to make lookup work more or less as it does now.

So it's not impossible, but some care has to be given the design and to handling compatibility. If anybody is interested, there are probably some nuggets of wisdom to mine from this old thread:

  https://lore.kernel.org/git/AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com/

In the meantime, I think the current wisdom is "don't name a branch HEAD". ;) We even added logic to "git branch" to forbid this, but tools like "git push" are a bit more flexible.

-Peff