Git Checkout tracking behavior with <start_point>?

Git Checkout tracking behavior with <start_point>?

[Cyrus Vafadari]

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

Re: Git Checkout tracking behavior with <start_point>?

[Stefan Moch]

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.

> 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

Re: Git Checkout tracking behavior with <start_point>?

[Jeff King]

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

> 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?

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