On 2020-12-08 at 02:16:07, Junio C Hamano wrote: > Jonathan Tan <jonathantanmy@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
