Make `clear-pr-merge-commit-message` manual to avoid conflicts with user settings

[fregante]

• Part of https://github.com/refined-github/refined-github/issues/5155
• Part of https://github.com/refined-github/refined-github/issues/5992

Why

GitHub implemented a per-repo option to decide this, meaning we’re effectively overriding it, regardless of what the user picks or leaves as default.

Given that this feature has been a little controversial and troublesome, I think making it manual would avoid these gripes.

Test URLs

• This PR, if you have merging permissions

Screenshot

[fregante]

cc @JelteF @sindresorhus @yakov116

[JelteF]

The gif and code look good to me. I'm not in a situation where I can test this locally, but making this setting manual would fix the issue that I'm having where it overrides the repo settings.

[yakov116]

I have VERY mixed feelings about this, I don't like the button there. I also think that the button should be a bit more description. @refined-github/maintainers?

[fregante]

We can alternatively reuse the “copy code block” button style to make it feel more native, but it would appear more in the middle.

I think the “Clear” button is pretty self-explanatory, even if “it doesn’t work well” (i.e. the co-authors are left behind, if any). We could use a more common “x in a circle” as seen in <input type=search> but that would probably make it worse.

[fregante]

I think we can merge this before the next release and see how it feels.

If this is too cumbersome, we can try to rework a logic to automate this again, with an easy way to revert it. For example:

Some bugfix (#174)

Description shortened by Refined GitHub: CustomizeReset

Co-authored-by: Topo Gigio <[email protected]>

Notice:

• the textarea isn't shown/touched until the user merges the PR

This allows us to default to a new message without overriding the native one, which is available on "Reset"

[karfau]

I "manually" tested with some defaults be enabling and disabling the feature. From my perspective the current solution in this PR with manually applying the clearing when wanted (like in a renovate PR), makes more sense.

[fregante]

My main concern with this PR is that an action that used to be automatic now requires a click. For people who like a clean description, this is a step back; for others who don't like it, they can already disable the feature.

The only concern I have with the previous behavior is that the feature is completely silent and "lossy", meaning RGH users who try to use the new GitHub option will be frustrated. My solution to that issue specifically would be to make the feature louder, i.e. show that RGH is altering the field.

An alternative solution to this PR would be just add a "Refined GitHub cleared this field. More info" notice to help them disable the feature if they don't like it. This is by far the easiest solution to implement.

[JelteF]

My main concern with this PR is that an action that used to be automatic now requires a click. For people who like a clean description, this is a step back; for others who don't like it, they can already disable the feature.

I don't think it's as big a step back as you suggest. People that like a clean description can already configure the same default on the repo where they want this (assuming they have those permissions).

I think requiring user input before overriding the repo default seems pretty reasonable. If you want to add a notice I think it makes more sense to add a notice telling people about the repo default.

[fregante]

can already configure the same default on the repo where they want this

I'm not going to change the setting in 100 repos and every fork I create. Also I can't change the settings in some of the repos I can push to because I'm just a collaborator. This is also why pr-branch-auto-delete still exists.

[yakov116]

I'm still not convinced, I feel this is undoing the feature.

[fregante]

Right. Alternatives? What about the other 2 options I proposed? We can't leave it as is

[JelteF]

I'm not going to change the setting in 100 repos and every fork I create.

That workflow makes sense too. I think my main problem is that it does the "wrong" (imho) default everywhere,and it does it without the user enabling it.

Imho the "correct" default would be to take the PR description as the commit message.

Another option would be to disable the current option by default, like is done for two others.

[JelteF]

To be clear, github itself now provides three ways of filling the commit message and to me they rank like this:

1. PR description: perfect, you have a useful commit message
2. empty: bad, you have a pretty much useless commit message
3. list of commit messages: horrible, your commit message is a mess and contains stuff like "wip", "address review"

The clear-pr-merge-commit-message was useful at first, because by default you would go from a horrible to a bad experience. But now it actively disables the most useful option on repos that take the effort to enable it.

And probably the worst part is, if you work together with others on a repo and use this setting as a way to make sure that everyone gets useful commit messages, then you have to ask everyone on your team that uses RGH to disable this setting.

[yakov116]

Right. Alternatives? What about the other 2 options I proposed? We can't leave it as is

Let me think about it and I will get back to you later today.

[yakov116]

What if we put the button next to the squash and merge?

[fregante]

It doesn't feel like the right place. Also there's already a "merge as administrator" checkbox there and our own "wait for checks"

To be consistent with other features, we can place some text below it, like for "sync PR commit title"