Re: Git Checkout tracking behavior with <start_point>?

From: Stefan Moch <stefanmoch@mail.de>
Date: Nov 3, 2021, 20:17 UTC
Message-ID: <10455b65-377f-5bd5-fd7e-c6cb44d2f82f@mail.de>
In-Reply-To: <CAMd+_QCDN5UwwC=ZRcT4Y3p1x7kCQ1TEVf5321Ykx4xrhv-YOA@mail.gmail.com>

Hello Cyrus,

Am 03.11.21 um 16:08 schrieb Cyrus Vafadari:

> I'm new to this mailing list, so I hope I'm doing it right!

Welcome! And yes.

Show 13 quoted lines

> I am an avid user of this pattern: "git checkout -b my_branch
> upstream/3.2.x", using "start_point" to build my backported patch
> against an old feature version. But in this case, the default tracking
> is against 3.2.x, rather than my new feature branch. So, then, when I
> push I specify to update the tracking against the new branch name.
> There are also various default behaviors for push, which I won't
> enumerate here, but in the end I need to specify tracking.
> 
> I'm wondering if there is some usage/pattern I'm missing?
> 
> Or is this an opportunity to add a gitconfig for "tracking behavior"
> of `checkout` with start_point? If there is agreement that this could
> be improved with a new config, I'd be happy to open a PR.

There is already a --[no-]track option[1] to the commands that create new branches (switch, branch, checkout, worktree) to toggle this behavior per command invocation, and also the configuration option branch.autoSetupMerge[2] to set the desired behavior generally.

Example:

1. check if not set, default behavior / your example

   $ git config branch.autoSetupMerge
   $ git checkout -b trackingtest_1 origin/master  # like you did
   Branch 'trackingtest_1' set up to track remote branch 'master'
   from 'origin'.
   Switched to a new branch 'trackingtest_1'

   (as you noticed: the start point is set as the new branch's
   upstream)

2. specify --no-track to prevent tracking branch creation for
   command:

   $ git checkout --no-track -b trackingtest_2 origin/master
   Switched to a new branch 'trackingtest_2'

   (no tracking branch created)

3. or, configure the general behavior (test without --no-track
   again):

   $ git config --local branch.autoSetupMerge false
   $ git checkout -b trackingtest_3 origin/master
   Switched to a new branch 'trackingtest_3'

   (no tracking branch created)

4. verify, what we just did:

   $ git branch --list 'trackingtest_*' -vv
     trackingtest_1 66262451ec [origin/master] Git 2.33-rc0
     trackingtest_2 66262451ec Git 2.33-rc0
   * trackingtest_3 66262451ec Git 2.33-rc0

   (only the first one has the remote tracking branch set)

5. to set the new remote tracking branch of the same name (and
   create it in the remote repository in one step)[3]:

   $ git push -u origin HEAD
   Branch 'trackingtest_3' set up to track remote branch
   'trackingtest_3' from 'origin'.
   Everything up-to-date

When you create the new branch, this happens only in the local repository – it is therefore a separate step (push) to create the branch in a remote repository. As this normally (without -u) would not change/set the upstream for the branch, this has to be done on the first push with '-u'. Using HEAD as a shortcut, you can push the currently checked out branch without specifying the branch name[4]. If there is already a branch with this name on the remote repository, the push will of course only work for fast-forwards, unless forced.

Rethinking it: if you are doing the 'git push -u origin HEAD' anyway – maybe even as first step after the branch creation –, or you don't intent to fetch/pull into this branch before the push, you can forego either using --no-track and setting branch.autoSetupMerge.

Stefan

[1] https://git-scm.com/docs/git-checkout#Documentation/git-checkout.txt---track [2] https://git-scm.com/docs/git-config#Documentation/git-config.txt-branchautoSetupMerge [3] https://git-scm.com/docs/git-push#Documentation/git-push.txt--u [4] https://git-scm.com/docs/git-push#Documentation/git-push.txt-codegitpushoriginHEADcode