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

From: Tao Klerks <tao@klerks.biz>
Date: Apr 20, 2022, 05:12 UTC
Message-ID: <CAPMMpogY5vZU8gyRSYh+BM4goPPtJw0cCiM-31sy-s_uGRv8uA@mail.gmail.com>
In-Reply-To: <Yl2qwO0SMPOhb5h9@google.com>

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!

Show 5 quoted lines

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