Re: [PATCH v11] checkout: extend --track with a "fetch" mode to refresh start-point

From: Junio C Hamano <gitster@pobox.com>
Date: May 21, 2026, 12:58 UTC
Message-ID: <xmqqtss02a2o.fsf@gitster.g>
In-Reply-To: <b8932b27-8006-4b43-b7e5-1fac0fbf42c7@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 11 quoted lines

>> One.  Have you considered the case where the remote-tracking refs
>> are overlapping, e.g., where "origin" and "upstream" point at
>> different URLs but they both store in "refs/remotes/upstream/*"?
>> Perhaps their URLs may textually be different but are pointing
>> logically at the same place (e.g., one ssh:// the other https:// for
>> example).
>> 
>> What should happen?  What does happen after you apply this patch?
>
> It would be worth looking at what "git checkout --track" does in that 
> case and seeing if we can share the code.

It always is a good idea to think how we can share code for different purposes to solve a new problem, but in this particular one, I am not sure if "git checkout -t -b topic upstream/main" codepath has much to offer to solve what the new "before the checkout, update from the remote" feature wants to do. To the former, it does not matter how refs/remotes/upstream/* are updated and by fetching which remote at all. The only thing it cares about is to leave the record that this new "topic" branch works with refs/remotes/upstrea/main. But the latter needs to be able to compute which remote it should fetch from. It is a problem that existing code had no need to solve.