From: Harald Nordgren Date: Thu, 18 Jun 2026 12:38:59 GMT Subject: Re: [PATCH v6] checkout: extend --track with a "fetch" mode to refresh start-point Message-ID: In-Reply-To: Hi Phillip! How do you feel now, is it worth it for us to move forward with this topic or not? Harald On Fri, May 8, 2026 at 3:15 PM Phillip Wood wrote: > > Hi Harald > > On 07/05/2026 21:12, Harald Nordgren wrote: > > Is this ready to move to next? > > I'm not particularly enthusiastic one way or the other about adding > this, but so long as we only try to fetch when the user explicitly asks > for it I don't particularly object. However having had a quick scan of > the implementation I have a few comments > > * "--track=inherit,direct" is nonsense and should be rejected > > * currently "--track" has "last one wins" behavior so > "--track=inherit --track=direct" behaves like "--track=direct". We > should probably keep that so that "--track=fetch --track=direct" > behaves like "--track=direct", not "--track=fetch,direct" > > * if "git fetch" fails and the remote tracking ref already exists then > we should print a warning and carry on rather than dying which is more > convenient if the user or remote server are offline. > > * "git checkout --track=fetch origin/branch" should respect > remote.origin.fetch so that we fetch the ref that we're going to > checkout. I wonder if we can share this logic with the code that > sets the upstream branch. > > * "git checkout --track=fetch origin" should only fetch the remote > ref that we're going to checkout, not all the refs from origin. i.e. > it should read origin/HEAD to work out what to fetch. > > Thanks > > Phillip >