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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 24, 2026, 22:21 UTC
Message-ID: <xmqqeck4xan3.fsf@gitster.g>
In-Reply-To: <pull.2281.git.git.1777024991531.gitgitgadget@gmail.com>

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 10 quoted lines

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

But I have to say that this one, especially the configuration variable, goes way too far. The usual uses of remote-tracking branch names, e.g.,

    git log -1 origin/master
    git grep frotz origin/master
    git rev-list --count origin/maint..origin/master

to name a specific object all assume and rely on the stability of them. Should the configuration cause a fetch to happen before any of these uses of remote-tracking branches for consistency?