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

From: Ben Boeckel <mathstuf@gmail.com>
Date: Jul 28, 2021, 18:26 UTC
Message-ID: <YQGhSTc9NoB4xEGA@erythro.dev.benboeckel.internal>
In-Reply-To: <xmqqim0u9vnb.fsf@gitster.g>

On Wed, Jul 28, 2021 at 10:48:56 -0700, Junio C Hamano wrote:

Show 9 quoted lines

> 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).

Show 12 quoted lines

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

Show 7 quoted lines

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

Show 10 quoted lines

> > +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).

Show 24 quoted lines

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

Show 13 quoted lines

> 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