On Wed, Jul 28, 2021 at 10:48:56 -0700, Junio C Hamano wrote:
> Ben Boeckel <mathstuf@xxxxxxxxx> writes:
>
> > The `branch.autoSetupMerge` works well for setting up tracking a local
> > branch, but there is no mechanism to automatically set up a remote
> > tracking situation.
>
> This description is probably insufficient to explain what's missing,
> probably because "set up a remote tracking situation" is a bit
> fuzzy.
Fair enough. I finally understood what was going on with "tracking" only
recently. Usually I would track the remote's branch of the same name,
but I found that "tracking" `origin/master` instead of `myfork/topic`
makes `fugitive` render the following:
- commits on my topic that aren't integrated (this makes it easy to
tell it to "amend this commit" using its keybinding;
- commits on `master` that aren't on my topic (so I can see if there's
anything relevant to rebase on top of); and
- diffs against my fork's branch (as last fetched) so that I can see
the status.
Maybe this is a tooling issue, but I saw this as a potential way to
avoid having to specify this information on every topic I create.
> Without this patch, I can do this already:
>
> $ git checkout -t -b topic origin/topic
I should note that the *vast* majority of my development is done using
the fork-based workflow. I have `remote.pushDefault` set to my fork and
I use `push.default = simple` (there are only a handful of repositories
where "my fork" is also `origin` and I have, on multiple occasions,
wanted to make forks even there).
My normal pattern is that I'm on the target branch already, so I have:
$ git checkout -b topic
which doesn't do any tracking. Just `-t` makes it track my *local*
`master` when I really want it to track `origin/master`. AFAIK, there's
no shortcut for this other than to give the full `-t origin/master` at
branch creation time (and as something I do all the time).
> And after the above, we have
>
> [branch "topic"]
> remote = origin
> merge = refs/heads/topic
>
> Of course, you can instead use a short-hand DWIM, e.g.
>
> $ git checkout topic ;# assuming origin/topic exists
>
> gives us the same thing. In either case, topic knows to integrate
> with the 'topic' branch from remote 'origin' and push back there.
This doesn't match with my usual experience in fork-based workflows. I
want the topic to track `master` and then my `remote.pushDefault` makes
sure it goes to "the right place" when pushing.
> So instead of saying "there is no mechanism to ...", be a bit more
> specific what you can and cannot do in this first paragraph.
>
> Then we can describe the solution we'd propose in the second and
> subsequent paragraphs.
>
> Thanks.
I'll work on an improved cover letter to give more background.
> > +branch.defaultRemote::
> > + When a new branch is created with 'git branch', 'git switch' or 'git
> > + checkout', this value will be used to initialize the
> > + "branch.<name>.remote" setting.
>
> You mean without "-t"? I offhand do not think of a reason why this
> is a good idea. How would one create local topic branches that you
> plan to merge locally into your own larger topic branch to be shared
> with others? Shouldn't there be an easy way to countermand the
> setting by this configuration?
Everything goes through merge requests for the projects I work on
day-to-day (even contributions to "my own" projects due to CI
workflows). I added a test that `--no-track` works for this case (which
given its rarity for me is the right tradeoff at least).
> > +branch.defaultPushRemote::
> > + When a new branch is created with 'git branch', 'git switch' or 'git
> > + checkout', this value will be used to initialize the
> > + "branch.<name>.pushRemote" setting.
>
> Ditto.
>
> > +branch.defaultMerge::
> > + When a new branch is created with 'git branch', 'git switch' or 'git
> > + checkout', this value will be used to initialize the
> > + "branch.<name>.merge" setting.
>
> So the expected use case is to fork multiple local branches, to
> integrate with the same branch from the remote? I think we can
> already do
>
> $ git checkout -t -b xyzzy origin/master
> $ git checkout -t -b frotz origin/master
>
> and you can lose -t with branch.autosetupmerge setting. As the "git
> branch" command needs to get the name of your branch (e.g. 'xyzzy'
> or 'frotz') and which remote tracking branch you start from
> (e.g. 'origin/master'), even with branch.{defaultRemote,defaultMerge}
> configuration, you wouldn't lose that many keystrokes, I suspect.
There are times that I want to branch from HEAD, but track `master` (for
example, a branch destined for backporting to an older branch). The
equivalent of:
$ git checkout release
$ git checkout -b backported-branch
$ git branch --set-upstream-to=origin/master
> Or do you plan to make
>
> $ git branch xyzzy
>
> a short-hand for
>
> $ git branch -t xyzzy origin/master
>
> when defaultRemote and defaultMerge are set to 'origin' and
> 'refs/heads/master'? It would be way too confusing to start the
> new branch from origin/master in such a case, as everybody learned
> that "git branch xyzzy" that does not say where the branch initially
> points at uses HEAD.
No, it would just *track* `origin/master`, not branch from it. It should
be shorthand for:
$ git branch xyzzy
$ git branch --set-upstream-to=origin/master xyzzy
Though I personally use `git checkout -b` far more often to create
branches. And since "every" branch I make would have `-t origin/master`,
I wanted to have configuration to do this part for me.
Hopefully this gives a clearer picture of where I'm coming from.
Thanks,
--Ben
