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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 17, 2025, 19:01 UTC
Message-ID: <xmqq1puva3cu.fsf@gitster.g>
In-Reply-To: <20250317180604.GB704553@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

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

Good point, and I do not think it should.

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

Again, I do not think it should update HEAD. Is this something hard to fix? When I say "please tell me where their main branch is", that is what I mean. I didn't ask about their HEAD, period. Unlike "git fetch" (that default to 'origin') and "git fetch origin", which is "please update our view of 'origin'" and should update HEAD if it is missing (or configured to be updated every time).

Show 15 quoted lines

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

Yup, I do think #1 is the way to go.

Thanks.