Re: [PATCH 0/2] limiting followRemoteHEAD being used

> Jeff King <peff@peff.net> writes:
>
> > There is one interesting case we haven't discussed. What should:
> >
> >   git fetch origin HEAD
> >
> > do with respect to refs/remotes/origin/HEAD? Right now it does nothing
> > (at least with the v2 protocol). We ask about HEAD, but since we didn't
> > fetch the matching ref, set_head() won't accept it. And after my
> > patches, we would not even try to call set_head() at all (since we are
> > not using the full refspecs).
> >
> > But it's also something I could see somebody doing to try to update
> > refs/remotes/origin/HEAD. I've left it alone for now, since my series
> > does not change the behavior either way. But it might be something we
> > could do on top (though it gets funny, because with the code as it is
> > now, we'd have to ask for all of refs/heads/ to see the pointed-to
> > branch advertised).
>
> With v2 protocol, we have direct knowledge of where their HEAD
> points at (when we ask for it), so we shouldn't even have to know
> about what they have under "refs/heads/".  I do not think it is
> within our contract that we'd somehow make sure that HEAD in a
> remote-tracking hierarchy is not dangling, or something.
>
> In any case, I agree that it is sensible to leave it out of these
> changes for now.