On Thu, Mar 13, 2025 at 08:53:53AM -0700, Junio C Hamano wrote:
> > 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.
That was my intuition, too, but there's a case in between. Doing:
git fetch origin main
will update HEAD, too (with the current code). But if and only if it
points to "main"! Is that something we want to keep? It feels like it
could sometimes be useful, but it is awfully hard to explain.
So I could see going in two different directions:
1. Only do the HEAD update when we are using the configured refspecs.
2. Do the HEAD update even when we are not fetching its destination,
but do not otherwise trigger ls-refs to discover it (so basically,
not on object-only fetches). This kicks in for more cases, but is
hard to explain.
Both are a user-visible divergence from how the feature behaves now (and
so I did not want to touch that in my series), but if we are all in
agreement, we can fix it on top. I do think option 1 (i.e., what you are
suggesting in your email) is how I would have done it if starting from
scratch. And the current rules are weird enough and the feature is new
enough that I think it is OK to change.
-Peff
