From: Harald Nordgren Date: Sat, 13 Jun 2026 17:38:03 GMT Subject: Re: [PATCH v11] checkout: extend --track with a "fetch" mode to refresh start-point Message-ID: In-Reply-To: <01526f43-86aa-466f-a1e8-054284e1a2e1@gmail.com> Hi Phillip and JCH! Would it be possible to get another look here to know if it's worth continuing with this topic. I think it's a useful feature, but the feedback from this list has been a bit lukewarm. Harald On Thu, May 21, 2026 at 4:06 PM Phillip Wood wrote: > > On 21/05/2026 13:58, Junio C Hamano wrote: > > Phillip Wood 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. > > >