Can csr interpret conventional merge commits?

[EliahKagan]

Usually a merge commit is not a conventional commit. Instead, if there are changes that should appear in a changelog, then one or more commits on a feature branch will be conventional, and they will make it in with the merge.

But if a merge commit is prefixes with something like fix!:, would csr interpret that to cover changes from the merge, compared to the base branch? Would other problems arise?

Please note that I'm asking about true merge commits, not commits that are produced by squashing. Those are often expected to be conventional, but they're not really merge commits because they have only one parent.

(The motivation is that there are strange cases where using a conventional merge commit could be tempting in light of things like GitoxideLabs/gitoxide#1952. I suspect that, regardless of the answer to this, a conventional merge commit would not be a good solution, and more broadly that one should not do this because its meaning would be unclear to human beings. But I do not know any of this to be so.)

[Byron]

If I remember correctly, the history-scanner will actively ignore merge commits even, and maybe only even follow the first parent.
But even if it didn't, I'd think it ignores merge commits.

If it would look at each commit unconditionally though, then I'd expect it to pick up conventional messages in merge-commits as well. However, I'd really think it doesn't.

[EliahKagan]

Thanks. I won't use merge commits in this way when csr needs to pick it up. If I get a chance to test this, then I'll let you know what I find.