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

From: Tao Klerks <tao@klerks.biz>
Date: Apr 20, 2022, 21:31 UTC
Message-ID: <CAPMMpohQei9vBBm=7hC=N5LPwzMCED=fZcXyePnrkLCHfCJTZw@mail.gmail.com>
In-Reply-To: <xmqqczhbr6pv.fsf@gitster.g>

On Wed, Apr 20, 2022 at 7:43 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

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

Show 5 quoted lines

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

Show 6 quoted lines

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