From: Junio C Hamano Date: Sun, 03 May 2026 20:59:47 GMT Subject: Re: [PATCH v5] checkout: extend --track with a "fetch" mode to refresh start-point Message-ID: In-Reply-To: "Harald Nordgren via GitGitGadget" writes: > From: Harald Nordgren > > A common workflow is: > > git fetch origin > git checkout -b new_branch --track origin/some-branch > > The first command exists so the second sees an up-to-date view of the > remote. If it is forgotten, origin/some-branch points at a stale > commit and the new local branch is created from the wrong start > point. As I pointed out multiple times, I prefer not to see this called "wrong". Even if you did not "forget", somebody may be pushing after you fetched and you may end up forking from a "stale" commit. So not fetching is not inherently "wrong", simply because that is how real world works. Multiple people working in a distributed environment does not give you absolute garantee that you will be "up to date", ever, which makes it wrong to call anything that is not "up to date" a "wrong starting point". > This only matters when the user is setting up tracking and > expects the new branch to start at the freshest tip; for a one-off > checkout of an arbitrary commit there is no reason to "freshen" the > start-point. I do not think "arbitrary" fits in this workflow description. If anything, "I'd take anything that the remote repository happens to have at the tip, even without having a chance to sanity checke if that is a good starting point" is more appropriate workflow to be described with a word "arbitrary commit". If you are checking out without forking from there, you'd more likely be checking out the "latest" you have fetched from the other side, often knowing exactly what it is after checking it with "git show origin/$topic". > Tie the new behavior to --track for that reason: Notice that the reader hasn't heard what "the new behaviour" is up to this point yet? How about rewriting everything up to and including this "Tie the new ..." line perhaps like so: If you want to fork your topic branch from the very latest of the tip of a branch your remote has, you would do: git fetch origin some-branch git checkout -b new_branch --track origin/some-branch Extend the "--track" option of "git checkout" and allow users to write git checkout --track=fetch -b new_branch origin/some_branch to (1) fetch 'some-branch' from the remote 'origin', updating the remote-tracking branch 'origin/some-branch', (2) arrange subsequent 'git pull' on 'new_branch' to interact with 'origin/some_branch' and (3) fork 'new_branch' from it. In the value of the '--track' option, 'fetch' can be combined with ...