From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 24 Apr 2026 22:21:20 GMT
Subject: Re: [PATCH] checkout: add --fetch to fetch remote before resolving start-point
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:

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