Subject: Re: Cloning empty repository uses locally configured default branch name

From: "brian m. carlson" <[email-masked]>
Date: Tue, 8 Dec 2020 02:32:01 +0000

On 2020-12-08 at 02:16:07, Junio C Hamano wrote:
> Jonathan Tan <[email-masked]> writes:
> 
> > 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".
> 
> Thanks for looking into this (I think this came up again today
> during my reviews of some topic).
> 
> It would be a backward incompatible change to add to v0, but at this
> point shouldn't we be leaving v0 as-is and move everybody to v2?
> 
> If it is a simple and safe enough change, though, saying "why not"
> is very tempting, though.

Yeah, I think this would be a nice thing to add to v2.  I've considered
adding a way to push symrefs (that is, update the head on the remote
side), but that would be a bit trickier.  Still, there's no reason the
fetch side couldn't learn a "symref" capability in the meantime.

I don't see a need for this in v0, since all versions of Git that
support this will also support v2.  I think it's okay if other clients
have to add support for v2 before they get the cool new features.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US