On Tue, Mar 18, 2025 at 12:18:41PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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. Ditto, and I am quite happy with the end-state of this series. > Thanks. Thanks, Taylor
