Re: [PATCH] checkout: add --fetch to fetch remote before resolving start-point

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 25, 2026, 02:54 UTC
Message-ID: <xmqqfr4jwxzi.fsf@gitster.g>
In-Reply-To: <xmqqeck4xan3.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 20 quoted lines

> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Harald Nordgren <haraldnordgren@gmail.com>
>>
>> Add a --fetch option to git checkout and git switch, plus a
>> checkout.autoFetch config to enable it by default. When set and the
>> start-point argument names a configured remote (either bare, like
>> "origin", or prefixed, like "origin/foo"), fetch that remote before
>> resolving the ref. Aborts the checkout if the fetch fails.
>>
>> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
>> ---
>
> It is true that "checkout" does funny things to special case the
> remote-tracking branches, like setting up the branch.<name>.merge
> configuration or even inferring the name of the local branch to be
> created.  
> ...
> ...  Should the configuration cause a fetch to happen before any
> of these uses of remote-tracking branches for consistency?

The last one was a rhetorical question. I do not want to see such a configuration variable to implicitly trigger fetching at all.

I am somewhat sympathetic to the desire "I want to be sure that I start the new branch in a state as fresh as possible". It is tied to the "--track" option of "git checkout -b topic --track origin/main". If you are merely starting at a single arbitrary commit, instead of anticipating to having to repeatedly sync with the remote-tracking branch that will subsequently move, there is no point jumping to a "freshest" commit that you haven't even seen let alone inspected (i.e., you do not even know if it is a good base to build on).

So instead of introducing a totally new option that can only be used only when "--track" is given, it might make more sense to introduce this as a variant of "--track", perhaps "--track=fetch,[in]direct" or something like that. And extend branch.autosetup{Merge,Rebase} that controls what happens when a branch is created with "checkout -t -b" or "branch --track" so that the remote-tracking branch gets updated, perhaps.

As to "git checkout origin/main" (nothing else on the command line), it has "magic" compared to "git checkout origin/main~0" already by treating the parameter not just as a SHA-1 expression that names a commit object but as a remote-tracking branch (this is necessary for "-t"). So I am not fundamentally opposed to the idea to give an option to treat that form specifically.

Having said all that, quite honestly, I prefer not to see any of the above changes, including the original patch. It leaves too many usability questions unaddressed. For a starter, if you interact with a repository with two or more branches, should

   $ git checkout --track=fetch -b topic origin/main

update an unrelated remote-tracking branch origin/maint from the same remote? As I already said, most Git tools _depend_ on the stability of remote-tracking branches---the desire to update the origin/main when a new branch that builds on origin/main is created may be a valid one, but it is unclear if that warrants updating other remote-tracking branches only because they come from the same remote repository. There may be a dozen other UI/usability issues that will be introduced if we start to "fetch from remote" automatically, but I won't even try to be exhaustive while I am still on a leave ;-)