From: Kristoffer Haugsbakk Date: Fri, 24 Apr 2026 17:38:28 GMT Subject: Re: [PATCH] checkout: add --fetch to fetch remote before resolving start-point Message-ID: <89f923bf-e5fc-4557-a2f0-d240db07eaf9@app.fastmail.com> In-Reply-To: On Fri, Apr 24, 2026, at 12:03, Harald Nordgren via GitGitGadget wrote: > From: Harald Nordgren > > 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 `/HEAD`. Doing a fetch on every would have been bad. > fetch that remote before > resolving the ref. Aborts the checkout if the fetch fails. > > Signed-off-by: Harald Nordgren > --- > 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 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 '")), > 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 is a remote-tracking ref")), Ditto. > OPT_END() > }; >[snip]