Git Checkout tracking behavior with <start_point>?

Hello all,

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

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.

Best, Cyrus

Hello Cyrus,

Am 03.11.21 um 16:08 schrieb Cyrus Vafadari:

Welcome! And yes.

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

On Wed, Nov 03, 2021 at 11:08:29AM -0400, Cyrus Vafadari wrote:

I think it all depends on your workflows and how you use the upstream information. For instance, I start most of my branches off of the tip of the remote master, similar to you:

  git checkout -b my-topic origin/master

I want to keep that as the upstream for various commands. E.g., "git-rebase -i" will use the fork point of the branch by default, without even having to say "@{upstream}".

When I push, it goes to a remote branch with a matching name (because I have push.default set to "current"). If I want to look at the remote-repo version (say, to compare what's happened since I last pushed), I use the "@{push}" shortcut to refer to it (rather than "@{upstream}"). So for example I often do:

  git range-diff @{push}...HEAD

to see what hasn't yet been pushed (range-diff rather than a regular "log" because I'm usually rewriting commits via rebase).

Now that's just what _I_ do. There's nothing wrong with setting the upstream to the push destination if your workflows prefer that (e.g., because you are collaborating with somebody else on the branch and want to be able to pull or rebase just the parts that haven't been pushed). And that's why we have "push -u".

But no, I don't think there's a way to set the upstream to that push destination at the time you run "git checkout". I don't think it would be an unreasonable config option to have. Once upon a time it was very tricky to say "the thing that I would push to by default", because those rules were all just encoded inside of git-push. But these days you should be able to reuse the logic that powers @{push}.

-Peff