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

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Fri, Apr 24, 2026, at 12:03, Harald Nordgren via GitGitGadget wrote:
> 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

Why is the config not `checkout.config`? So it’s named the same as the
option (modulo snake case/camel case which is not relevant here).

> start-point argument names a configured remote (either bare, like
> "origin", or prefixed, like "origin/foo"),

It’s great that it only fetches when you have a remote-tracking branch
or alias for `<remote>/HEAD`. Doing a fetch on every <start-point> would
have been bad.

> fetch that remote before
> resolving the ref. Aborts the checkout if the fetch fails.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
>     checkout: add --fetch to fetch remote before resolving start-point
>
>     A workflow I run several times a day looks like:
>
>     git fetch origin
>     git checkout -b new_branch origin/some-branch
>
>
>     The first command exists purely to make the second one see an up-to-date
>     view of the remote. If I forget it, origin/some-branch points at a stale
>     commit, and I end up creating a local branch from the wrong starting
>     point.
>
>     This series teaches git checkout (and git switch) a new --fetch flag
>     that folds the two steps into one:
>
>     git checkout --fetch -b new_branch origin/some-branch

The motivation for why this is being proposed maybe might as well go in
the commit message. Maybe that’s just me.

The commit message just says that “this thing is added”. Not why.

>
>
>     When the start-point argument names a configured remote — either bare
>     (origin, which resolves to the remote's default branch) or in / form —
>     git fetch is run before the start-point is resolved. If the fetch fails,
>     the checkout aborts and no local branch is created.
>
>     A new checkout.autoFetch config option enables the same behavior by
>     default, for users who always want it.
>
> Published-As:
> https://github.com/gitgitgadget/git/releases/tag/pr-git-2281%2FHaraldNordgren%2Fcheckout-fetch-start-point-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git
> pr-git-2281/HaraldNordgren/checkout-fetch-start-point-v1
> Pull-Request: https://github.com/git/git/pull/2281
>
>  builtin/checkout.c    | 48 ++++++++++++++++++++++++++++++++++++++--
>  t/t7201-co.sh         | 51 +++++++++++++++++++++++++++++++++++++++++++
>  t/t9902-completion.sh |  1 +
>  3 files changed, 98 insertions(+), 2 deletions(-)

I guess a later version will have the changes to the documentation.

>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
>[snip]
>  		argv += n;
>  		argc -= n;
>  	} else if (!opts->accept_ref && opts->from_treeish) {
> @@ -2052,6 +2092,8 @@ int cmd_checkout(int argc,
>  		OPT_BOOL(0, "overlay", &opts.overlay_mode, N_("use overlay mode
> (default)")),
>  		OPT_BOOL(0, "auto-advance", &opts.auto_advance,
>  			 N_("auto advance to the next file when selecting hunks
> interactively")),
> +		OPT_BOOL(0, "fetch", &opts.auto_fetch,
> +			 N_("fetch from the remote first if <start-point> is a remote-tracking ref")),

s/remote-tracking ref/remote-tracking branch/ ?

git(1) doesn’t have a namespace for tracking refs in general.

>  		OPT_END()
>  	};
>
> @@ -2102,6 +2144,8 @@ int cmd_switch(int argc,
>  			 N_("second guess 'git switch <no-such-branch>'")),
>  		OPT_BOOL(0, "discard-changes", &opts.discard_changes,
>  			 N_("throw away local modifications")),
> +		OPT_BOOL(0, "fetch", &opts.auto_fetch,
> +			 N_("fetch from the remote first if <start-point> is a remote-tracking ref")),

Ditto.

>  		OPT_END()
>  	};
>[snip]