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
