]> git.ipfire.org Git - thirdparty/git.git/commit
checkout: extend --track with a "fetch" mode to refresh start-point
authorHarald Nordgren <haraldnordgren@gmail.com>
Wed, 24 Jun 2026 21:54:58 +0000 (21:54 +0000)
committerJunio C Hamano <gitster@pobox.com>
Wed, 24 Jun 2026 22:06:02 +0000 (15:06 -0700)
commit8b13e2d194d5e1c2280d33de6b64c778a9cfa2ff
treef5bae31774ff829f376a92130931cb6e4e795b00
parentf4914a86e11be463819175ce769c3b689bbb9994
checkout: extend --track with a "fetch" mode to refresh start-point

Forking from an existing remote branch without refreshing first often
has consequences: you start work that has already been done, or you
build on an old version of the code which causes big conflicts later
when you pull. The workaround is two commands ("git fetch <remote>
<branch> && git checkout -b <topic> <remote>/<branch>"), and when
the fetch is skipped the checkout silently starts from a stale tip.

Users may already expect "<remote>/<branch>" to refer to the latest
tip on the remote. While this blurs the line between fetch and
checkout, git already does this in places where it pays off: "git
clone" fetches and checks out, and "git pull" fetches and merges.

Add a "fetch" mode to "--track" that refreshes <start-point> before
checking it out:

    git checkout -b new_branch --track=fetch origin/some-branch

Only the requested branch is fetched so other remote-tracking
branches are left untouched. When <start-point> is a bare <remote>
(e.g. "origin"), follow refs/remotes/<remote>/HEAD to learn which
branch to refresh. If "git fetch" fails but the remote-tracking ref
already exists locally, warn and proceed from the existing tip,
otherwise abort.

Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-checkout.adoc
Documentation/git-switch.adoc
builtin/checkout.c
t/t7201-co.sh