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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 28, 2026, 01:47 UTC
Message-ID: <xmqqwlxrzwid.fsf@gitster.g>
In-Reply-To: <pull.2281.v4.git.git.1777228346809.gitgitgadget@gmail.com>

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

> From: Harald Nordgren <haraldnordgren@gmail.com>

Show 7 quoted lines

> A common workflow is:
>
>     git fetch origin
>     git checkout -b new_branch origin/some-branch
>
> The first command exists purely so the second sees an up-to-date view
> of the remote.

This is only half true, isn't it?

Git is among projects that encourage forking only from a well-known point in history (like the latest released version), not at a random "tip of the day" commit from the upstream.

Such projects also tend to discourage people from constantly pulling updated upstream into their unfinished topic branch, or rebase their unfinished topic branch on top of updated upstream, only to "catch up", and instead encourage them to make a trial merge to notice when the base got too stale to cause eventual merge to conflict too much, and when it happens, make such a back-merge, but otherwise keep working on the stable base and avoid such "catching up".

And when working with such a project, what users who do the above is forgetting is to inspect origin/master between the two steps to see if it is a good commit to start your topic at.

> If it is forgotten, origin/some-branch points at a stale commit
> and the new local branch is created from the wrong start point.

So this part is not quite true. What makes your topic begin at a wrong starting point is not that you forget to fetch, but you forget to verify what you fetched and think if it is a good starting point.

And for that verification to happen, you do not want "checkout" and "fetch" mixed into one.

On the other hand, if you are allowed to fork at anywhere (as opposed to a latest release), then not fetching and building on top of slightly older codebase is not such a huge deal, as you're likely to be making the "catch up" changes on top of your unfinished work later anyway.

So as I already said before, I am fairly negative on this topic. It feels more like a knob to allow and actively encourage people to be more sloppy than anything else.

I may have already pointed this out (but I do not remember), but this option would not make any sense when --track is not in effect, so instead of adding a brand new option, making it an extension to the existing --track option might make it slightly more palatable.