Re: [PATCH 1/1] config: support setting up a remote tracking branch upon creation

[Ben Boeckel <mathstuf@gmail.com>]

On Wed, Jul 28, 2021 at 10:48:56 -0700, Junio C Hamano wrote:
> Ben Boeckel <mathstuf@gmail.com> 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