From: Phillip Wood <phillip.wood123@gmail.com>
Date: Thu, 21 May 2026 14:06:35 GMT
Subject: Re: [PATCH v11] checkout: extend --track with a "fetch" mode to refresh start-point
Message-ID: <01526f43-86aa-466f-a1e8-054284e1a2e1@gmail.com>
In-Reply-To: <xmqqtss02a2o.fsf@gitster.g>

On 21/05/2026 13:58, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>>> 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.

Don't we want to avoid creating a branch with an ambiguous upstream so 
that a subsequent "git pull" works though? Looking at 
branch.c:setup_tracking() it seems to reject upstream branches that 
match more than one remote.

Thanks

Phillip

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