Re: [PATCH] transport-helper: do not request symbolic refs to remote helpers

[Mike Hommey <mh@glandium.org>]

On Thu, Jan 22, 2015 at 09:52:55AM -0800, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > The patch changes the behavior in all cases, because it didn't feel
> > necessary to have a different behavior between the "normal" case and the
> > '?' case: it makes sense to request the ref being pointed at than the
> > symbolic ref in every case.
> >
> > Moreover, this makes existing non-git remote-helpers work without
> > having to modify them to provide a refspec for HEAD (none of the 5
> > mercurial remote-helpers I checked do).
> 
> I do not question the latter.  It is not surprising if all of them
> share the same limitation that shares the same root in the same
> impedance mismatch.
> 
> The trouble I had in supporting "makes sense ... in every case" was
> that you said that the code as patched would not work for a symref
> pointing at another symref.  The original code did not have that
> problem with remote helpers that support the 'list' command.
> 
> Does the new code avoid regressions for them and if so how?  That is
> what was needed in the justification.
> 
> For remote helpers that support the 'list' command, asking for a
> symref and asking for a ref that the symref points at both work OK
> and behave the same, and hopefully that would be true even when the
> latter is a symref that points yet another ref, so dereferencing
> only one level on our end when making a request, instead of letting
> the remote side dereference, is not likely to cause regression.

If I'm not mistaken, in that case with more than one level of symref,
nothing would break more than it already is, the bug would only not be
fixed for that case. That said, does this theoretical double indirection
actually happen in the wild? For one, afaict, it's not even possible to
create such a double indirection with git update-ref. You have to edit a
.git/refs/ file manually.

Mike