> On Mon, Dec 07, 2020 at 05:31:20PM -0800, Jonathan Tan wrote: > > > 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@xxxxxxxxxxxxxxxxxxxxx/ > > 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... > > > 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.
