Re: [PATCH v4] merge: new autosetupmerge option 'simple' for matching branches

[Tao Klerks <tao@klerks.biz>]

On Wed, Apr 20, 2022 at 7:43 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Tao Klerks <tao@klerks.biz> writes:
>
> > ...
> > To choose either option permanently, see push.default in 'git help config'.
> > ---
> >
> > I would propose to add one sentence at the end along the lines of:
> > ---
> > To instead avoid automatically configuring upstream branches when
> > their name doesn't match the local branch, see option 'simple' of
> > branch.autosetupmerge in 'git help config'.
> > ---
> >
> > Does that make sense to you?
>
> Two questions.
>
>  - If a user follows the push.default advice, does it have any
>    advantage to set branch.autosetupmerge=simple at all?

Probably not?

It really depends what they set push.default to:
* If they set it to upstream/tracking, then
branch.autosetupmerge=simple doesn't make much sense. You can set
both, but the outcome is effectively the same as setting push.default
to simple - not very useful.
* If they set it to "current", then it probably doesn't make sense
because what they're angling for is probably a triangular workflow,
which branch.autosetupmerge=simple very explicitly doesn't support /
doesn't make sense for. "matching" seems to be an extreme version of
the same setup.
* If they set it to "nothing" I'm not sure - I haven't understood in
what workflows that makes sense.

Generally, I expect that branch.autosetupmerge=simple makes the most
sense with push.default left at the default of "simple", for...
"simple" workflows :)

>
>  - If a user follows the branch.autosetupmerge=simple advice, what
>    happens their "git push" on a branch that the .merge is not set
>    due to this configuration?  Shouldn't they have to set up the
>    push.default for these branches anyway?

If the user follows the branch.autosetupmerge=simple advice (and
leaves push.default at the "simple" default), what they get at push
time will depend on whether they branched from a same-name remote
branch or anything else:

If they branched from a same-name remote branch, their "git push" will
be perfectly uneventful / unsurprising: they will simply push to the
remote branch. This is the same as without
branch.autosetupmerge=simple.

If they branched from a different-name remote branch (they created an
new / independent local branch), then no remote tracking relationship
will have been set up, and instead of the "fatal: The upstream branch
of your current branch does not match
the name of your current branch" error and advice, they will get a
much simpler error and advice:

---
fatal: The current branch whatevs has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin whatevs
---

When they follow those instructions, they will be in the "simple"
setup same as if they had just branched from same-name.

Importantly, as soon as they enable branch.autosetupmerge=simple, they
never see the original mismatching-name error and advice anymore -
they never again end up with mismatching names at all. (except in edge
cases like branch renames)

>
> While it might be a good thing to mention branch.autosetupmerge
> configuration variable, I am not sure if "To instead avoid" is a
> good thing to say here.  It sounds as if the user can ignore
> push.default as long as branch.autosetupmerge is taken care of, but
> I suspect that is not the case.

I disagree. If they get that error and advice, then their push.default
is set to "simple". If they then set their branch.autosetupmerge to
"simple" also, this is the simple coherent setup that I, at least,
would recommend to non-experts.

> Setting the latter to 'simple'
> means there are *MORE* branches that do not have .remote/.merge set
> up, doesn't it?  Which in turn means that we are relying more on
> what push.default is set to, right?

No - the idea here is that instead of telling push.default to do
something *independent* of the tracking branch (like, for example,
"current"), the setup the user ends up with is one where the tracking
branch, if there is one, is always the same-name where you will push
to.

When you create a new branch (by branching with a new name), your new
branch doesn't initially have an upstream tracking branch - and that's
right and correct, there's literally nothing on the server for you to
track yet - but the first time you push, the (existing) advice
encourages you to set up that tracking relationship. In this flow you
very explicitly *don't* rely on push.default, because you never want
to end up in a confusing (un-simple) situation where what you're
pulling from and what you're pushing to aren't the same thing - a
triangular workflow.

The "push the current branch and set the remote as upstream" advice is
consistent with how many/most GUIs will handle first push for a branch
that does not have an upstream tracking relationship yet - GUIs will
typically automatically specify (or set the UI default to) the
"--set-upstream" option on that first push.