From: D. Ben Knoble Date: Fri, 24 Apr 2026 17:12:36 GMT Subject: Re: [PATCH] checkout: add --fetch to fetch remote before resolving start-point Message-ID: In-Reply-To: On Fri, Apr 24, 2026 at 6:08 AM 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 > 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 > --- > 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. When you realize this, "git pull --rebase" should help correct it. > > 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 > > > 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. I could certainly see this being convenient. (I don't have any comment on the code at this time.)