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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 18, 2025, 19:18 UTC
Message-ID: <xmqqmsdi2lm6.fsf@gitster.g>
In-Reply-To: <20250318053905.GA2051217@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 16 quoted lines

> 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.

Thanks.