Restore functionality from `sync-pr-commit-title` removed in #2738 #2768

I removed it because merge commits are indistinguishable, so in a list it looks like that commit added a feature and then the following commits did the same. If the merge commit title is the default (Merge X into Y) then it’s more clear

I think it you want to keep each commit in history it’s best to rebase them.

Can you show me an example of a merge commit you made?

Well my commits previously looked like this:

fix: typo on main page (#9123) <-- this is the merge commit
fix: typo on main page

I feel that the whole Merge pull request #9123 into develop is too verbose and distracting, so if the merge commit message is the same as commit message, then it makes it easier to skim through, and the rebases are not allowed in my repo.

But perhaps you are right it may not make much sense to other people.

I personally think merge commits are just noise in most cases, so I may not be the right person to talk about them. In that example I just don’t see it being an advantage over the current situation.

I’d perhaps suggest we restore an old feature that made merge commits distinguishable (and if I remember correctly also dimmed them). We dropped it because there’s no “merge commit class” in the DOM anymore, so we could instead detect them if their title starts with Merge and contains into

I personally really liked the merge renaming when it was done like that: fix: typo on main page (#9123). And my entire team did too. Would be ok with is being Merge fix: typo on main page (#9123) to distinguish them from squashed merges too.

I do agree with @fregante that merge commits are kinda noisy, but not every org or team is able to have squash merge as a default.

Or maybe users should be given the option to choose if they care about distinguishing? Although I guess that defies the point of an opinionated git extension. I just thing this opinion may be dismissed too quickly.

@bastienboutonnet if you name it as Merge fix: typo..., this breaks the semantic commit naming rules

https://www.conventionalcommits.org/en/v1.0.0/

I was not aware you were sticking to those rules. Just so that I can understand. What point does it break actually? I'm trying to see how the default merge commit message from github does not violate those conventions.

@fregante what was the old feature like:

I’d perhaps suggest we restore an old feature that made merge commits distinguishable (and if I remember correctly also dimmed them). We dropped it because there’s no “merge commit class” in the DOM anymore, so we could instead detect them if their title starts with Merge and contains into

Because that could be good also :)

https://github.com/sindresorhus/refined-github/pull/1121

PR welcome to add a dim-merge-commits feature

This would solve the "noise" concern, for everyone.

It would have to use a combined GraphQL query to determine which commits on the current page are merge commits, and then just apply opacity: 0.6 on their whole line. Or something like that.

"Combined GraphQL query" example: https://github.com/sindresorhus/refined-github/pull/2795/files#diff-04c19a6c246911e079b45f999eab501cR14-R22

Test URL

https://github.com/babel/babel/commits/master?after=ddd40bf5c7ad8565fc990f26142f85613958a329+104

I moved the “dimmed merge commits” suggestion to https://github.com/sindresorhus/refined-github/issues/2827

cc @bastienboutonnet

As a solution to this issue, a new feature could be added: clean-merge-commit-title to create default merge commits as Merge of #133 for example, so it’s less noisy than the default

@fregante I totally buy that!

@fregante

Nice idea but I suggest one thing to consider:

It seems visually easier to skip a merge commit if it has almost exactly the same title as the normal commit. For example, this:

fix: bug in home page (#9345) 
fix: bug in home page

seems easier to skim than this:

Merge PR #9345
fix: bug in home page

It's easier to skim it if you just avoid merge commits altogether, what's the point? Change the politics if it doesn't help your work. Squash commits and the problem disappears.

#2827 will help reduce the noise at least on GitHub.com

@fregante fair enough, agreed

I opened a more specific issue ⬆️

Just to add my perspective, we use both merge commits and "squash and merge" in our project, using merge commits where it's necessary or desirable to preserve history, like for a feature branch. I like linear history for seeing what's actually happened on the default branch and even if you use merge commits you can get this with git log --first-parent, but that only works if the merge commit message isn't utter garbage, which is what GitHub gives you by default. A merge commit message that matches the PR title and body gives you exactly what I'm looking for. Anyway, I think this is getting implemented in https://github.com/zachwhaley/squashed-merge-message, so it's not a super pressing issue for me, but something to consider.

Digging a bit more into the details, in our project we actually have two independent long-lived branches which we merge back and forth between. Doing that without merge commits would be infeasible (I experimented with it).