Jeff King <peff@xxxxxxxx> 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.
> 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.
