Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

From: Jeff King <peff@peff.net>
Date: May 31, 2017, 04:43 UTC
Message-ID: <20170531044349.bcb6jlte5gmo6p6v@sigill.intra.peff.net>
In-Reply-To: <48CB2547397B471C99F54CFB3F113C3F@PhilipOakley>

On Sun, May 28, 2017 at 12:21:50PM +0100, Philip Oakley wrote:

Show 10 quoted lines

> > Are you aware of the symref capability that is already advertised in
> > the initial upload-pack response?  Right now, we do so only when
> > HEAD actually points at something, and the earlier suggestion by
> > Peff is to do so unconditionally, even when HEAD is dangling.
> 
> The suggestion is the otherway around. I would argue (as a viewpoint) that
> what we advertise are object IDs and their associated refs, sorted by ref
> name. (I'm thinking of the git/Documentation/technical/pack-protocol.txt
> here). My suggestion was that when we get to the sorted ref that HEAD points
> to (including the unborn oid) that we annotate that ref.

It's hard to do that in a backwards-compatible way. The reason the symref capability works like it does (and supports only HEAD) is that the bits after the NUL are treated as a capability string, and older clients will actually _replace_ any earlier capability string they saw with the new one. So:

  1234abcd refs/heads/a\0symref=refs/heads/target1
  5678abcd refs/heads/b\0symref=refs/heads/target2

doesn't work as you'd like.

But even if it did, I don't think that solves the dangling symref problem by itself. As you note, we'd need to advertise a null sha1 line and annotate that. I didn't test, but I'd suspect that's another compatibility problem; clients will probably choke on the null sha1.

> I didn't quite follow Peff's suggestion as to where the list change
> went and if that was a protocol change.

The current protocol just advertises symref=source:target in the capability line, where "source" does not have to be the ref that is currently being advertised at all. So you are free to do:

  1234abcd refs/heads/unrelated\0...symref=HEAD:refs/heads/target

But the server does not bother to do so when the HEAD symref doesn't point to anything. We could fix that without changing the protocol syntax. It's possible that some picky client would complain that we mentioned the HEAD symref even though it was not advertised, but certainly older git.git clients are fine with it. They'd still need a client-side update in order to do something useful with it, but at least its presence would not make older clients behave any worse.

-Peff