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

[Tao Klerks <tao@klerks.biz>]

On Mon, Apr 18, 2022 at 8:15 PM Josh Steadmon <steadmon@google.com> wrote:
>
>
> I think this is a good solution for relatively inexperienced users, and
> I don't see any issues with the implementation or tests.

Yay, thanks for the feedback!

> However, I
> wonder how users for whom this may be useful are going to discover this
> option? I don't expect that such users are going to be watching Git's
> release notes looking for new features such as this, or carefully
> reading documentation changes.

Honestly, I was being a bit selfish here - I effectively control the
gitconfig of "my" users, so I was planning on enabling this by default
and letting it "settle in" in git at large, eventually proposing to
change the default.

I understand/agree that this is a little naive - if no-one has reason
to try the new behavior, very little information as to its
usefulness/appropriateness is likely to emerge, and it will never be
an obviously good idea to change the default.

>
> In the discussion on v3 of this series, you mentioned you were thinking
> about adding an advice setting to point users here; is there a reason
> why that didn't make it into v4?

The advice I mentioned I would work on wasn't actually about this new
setting/behavior, but rather about the previously existing (and
reasonably unrelated) "not tracking: ambiguous information for ref"
error, which I found to be unreasonably cryptic.

I submitted that advice change as
https://lore.kernel.org/git/pull.1183.v7.git.1648793113943.gitgitgadget@gmail.com/,
and it's gone out in a recent release.

> It seems appropriate to me to add one,
> perhaps at the point where a user with "autosetupmerge=true" would run
> into a failure when trying to push?

Having thought about this a bit, I agree. On the one hand I'm a little
nervous about adding this kind of public behavior change as I would
imagine it's more likely to encounter resistance here, on the other
hand I do think it will make the changes themselves much more useful.
Also, this patchset hasn't moved in a while, so "holding it up" with
new changes may not be a significant concern.

the current advice looks something like:
---
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:master

To push to the branch of the same name on the remote, use

    git push origin HEAD

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?