Re: Cloning empty repository uses locally configured default branch name

On Mon, Dec 07, 2020 at 05:31:20PM -0800, Jonathan Tan wrote:

quoted

When cloning an empty repository, a local branch is created. But its
name is not the name of the branch that the remote HEAD points to - it
is the locally configured default branch name. This issue arose at
$DAYJOB and, from my memory, it is also not an uncommon workflow to
configure things online on a repo host and then use "git clone" so that
things like remotes are automatically configured.

Has anyone looked into solutions for this? Both protocol v0 and v2 do
not send symref information about unborn branches (v0 because, as
protocol-capabilities.txt says, "servers SHOULD include this capability
for the HEAD symref if it is one of the refs being sent"; v2 because
a symref is included only if it refers to one of the refs being sent).
In protocol v2, this could be done by adding a capability to ls-remote
(maybe, "unborn"), and in protocol v0, this could be done either by
updating the existing "symref" capability to be written even when the
target branch is unborn (which is potentially backwards incompatible) or
introducing a new capability which is like "symref".

We discussed this a few years ago, and I even wrote a small patch (for
v0 at the time, of course):

  https://lore.kernel.org/git/20170525155924.hk5jskennph6tta3@sigill.intra.peff.net/ (local)

A rebased version of that patch is below (it needed updating to handle
some namespacing stuff). Coupled with your patch here for the truly
empty repo case, it makes the server side of v0 do what you'd want.

But the client side needs to handle it, too. See the linked thread for
some discussion.

Thanks for the pointer.

I wouldn't be too worried about the backwards incompatibility of sending
a symref line in the capabilities that doesn't point to a ref we're
sending. Old clients are quite likely to ignore it. But...

quoted

A small issue is that upload-pack protocol v0 doesn't even write the
blank ref line ("000...000 capabilities^{}") if HEAD points to an unborn
branch, but that can be fixed as in the patch below.

I would worry how clients handle this bogus entry in the ref
advertisement. It looks like the actual Git client is OK, but what about
jgit, libgit2, etc? That's not necessarily a deal-breaker, but it would
be nice to know how they react.

That bogus entry is defined in the protocol and JGit both produces and
consumes that line. Consumption was verified by patching Git with my
patch and running the following commands in separate terminals:

~/git/bin-wrappers/git daemon --port=9425 --base-path=. .
sudo tcpdump -i any port 9425 -w -
~/jgit/bazel-bin/org.eclipse.jgit.pgm/jgit ls-remote git://localhost:9425/empty

And production:

~/jgit/bazel-bin/org.eclipse.jgit.pgm/jgit daemon --port=9426 .
GIT_TRACE_PACKET=1 git ls-remote git://localhost:9426/empty

(Note that the JGit CLI does not have a separate --base-path parameter.)

I have not checked libgit2, but quite a few servers use JGit out there,
so it presumably should be able to interoperate with them and hence
support the bogus entry.

It also only helps with v0 (and I agree with the sentiment that it would
be OK to ignore v0 at this point). For v2, we'd have to issue a HEAD
line like:

  0000000000000000000000000000000000000000 HEAD symref=refs/heads/foo

That probably would break clients, but the unborn capability should take
care of that.

Yes - or a special string like "unborn" in place of the 000.000.