Bug: Ignore merge commits by default

[jerome-benoit]

I've already read the rationale in previous issues about why it will be not be done and found it rather fallacious: the goal of a commit message checking tool is to focus only on human inputs and bypass automated ones.

It's basically a human-machine inputs checker and not a machine-machine inputs checker. Furthermore, I do not see why adding a tunable to add a regex to ignore at various level would be an issue.
For example, a simple GitHub or GitLab PR sync make to whole tool definitively fails in the PR branch without any possible workarounds and any strong rationale behind that.

[thekaveman]

I've already read the rationale in previous issues about why it will be not be done and found it rather fallacious: the goal of a commit message checking tool is to focus only on human inputs and bypass automated ones.

It has never been a goal of this commit message checking tool to worry about merge commits. They simply do not come into play during the day-to-day workflow of the people that maintain this tool.

For example, a simple GitHub or GitLab PR sync make to whole tool definitively fails in the PR branch without any possible workarounds and any strong rationale behind that.

Of course there are always workarounds. For example, git pull --rebase or even better the following git config:

git config pull.rebase true
git config rebase.autoStash true

I do not see why adding a tunable to add a regex to ignore at various level would be an issue.

I don't either, this is an open source project after all. Anyone can submit a suggested code change. Until #103 no one had done so, even as this continued to be a hot topic in the issues. Again, we just haven't prioritized working on features that aren't directly impactful to our day-to-day workflow.

All that being said, if you look at #119 you will see that the changes from #103 have been incorporated and modified so that this behavior (skipping merge commits) will be the new default going forward.

I will leave you with some simple advice for your next open source interaction: rather than creating yet another thread for a topic that has clearly had a lot of discussion and little actual work (with a condescending tone no less) -- come to the table with some code, some concrete suggestions, something to look at and work with. It is a much more helpful starting place.

Dupe of #39, #76, #84.

[jerome-benoit]

Of course there are always workarounds. For example, git pull --rebase or even better the following git config:

git config pull.rebase true
git config rebase.autoStash true

A setup workaround that ends up breaking the commits history by automatically squashing individual commits without consent or requiring to go tediously the branch history to choose manually the commits to squash cannot be called a workaround.

I will leave you with some simple advice for your next open source interaction: rather than creating yet another thread for a topic that has clearly had a lot of discussion and little actual work (with a condescending tone no less) -- come to the table with some code, some concrete suggestions, something to look at and work with. It is a much more helpful starting place.

When the issue has already been rejected several times with a rather fallacious rationale, user valid inputs ignored because of the former, not tracked, it's clearly not an invitation to anyone to start coding work on it.

Next time you try to give an advice on how to be helpful in FOSS community, try to apply it to yourself first:
by actually taking into account the user input and by not considering the user use case as being a corner case not needing any consideration (and even a simple issue tracking), especially when the very same issue is raised several times. It's one of the worst form of condescension that a FOSS project maintenance can do.

Nonetheless, that issue seems now to be tackled in an PR to be merged, at least ... after several years.

[thekaveman]

My friend:

this is an open source project after all.

Nothing at all has prevented you from making this change yourself (whether here as a PR or in your own fork). I appreciate your passion, but again, there is only so much we can prioritize at a given time.