Re: [PATCH 8/9] fetch: avoid ls-refs only to ask for HEAD symref update

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 13, 2025, 15:53 UTC
Message-ID: <xmqq4izxq63y.fsf@gitster.g>
In-Reply-To: <20250309032016.GH2334191@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> When we fetch from a configured remote, we may try to update the local
> refs/remotes/<origin>/HEAD, and so we ask the server to advertise its
> HEAD to us.

Yes.

I _think_ flipping the remote-tracking HEAD should be tied to the case where we are fetching to update the remote-tracking branches.

Show 13 quoted lines

> But if we aren't otherwise asking about any refs at all, then we know
> this HEAD update can never happen! To consider a new value for HEAD,
> the set_head() function uses guess_remote_head(). And even if it sees an
> explicit symref value for HEAD, it will only report that as a match if
> we also saw that remote ref advertised, and it mapped to a local
> tracking ref via get_fetch_map().
>
> In other words, a fetch like this:
>
>   git fetch origin $exact_oid:refs/heads/foo
>
> can never update HEAD, because we will never have fetched (nor even see
> the advertisement for) the ref that HEAD points to.

Good observation, and I actually think it would be counter-intuitive if remote HEAD gets updated by a fetch that does not even update the remote-tracking branches.

My preference is to keep the rule simple.

    If you fetch using the configured fetch refspec, i.e. "git fetch
    [<remote>]" without any refspec command line arguments, that is
    an operation to maintain your remote-tracking branches for that
    remote up-to-date, hence we also try to flip remote-tracking
    HEAD (if you told us to) during such a fetch.

If you are doing a single-object fetch (perhaps as a lazy-fill from promisor remote), I do not think I want to see anything else happen than that the single-object comes here.

Thanks.