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

From: Phillip Wood <[email-masked]>
Date: Fri, 8 May 2026 14:15:51 +0100

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