Add support to ignore reverted commits

[schoetbi]

I just reverted a (conventional) commit. The problem is, that in the release notes this feature is still included. I have not found a way to exclude (ignore) a commit.

Would it be a good idea to add parsers that ignore previously added commits? For example, I have the following history.

• sha=a001 message=Start
• sha=a002 message=feat: a new feature

- ...

• sha=a003 message=revert a002 feat: a new feature

If git cliff supported revert parsers, I could do something like this

commit_parsers = [
# ...
 { message = "^revert\s+(?<sha>.{40})", revert="true" }
]

Another option would be to add the git SHA explicitly

commit_parsers = [
# ...
 { sha = "7976e3a76d3a27e8024d95eeb51d75bbd7391e95", skip="true" }
]

Or is there another option that I did not find in the documentation?

[welcome]

Thanks for opening your first issue at git-cliff! Be sure to follow the issue template! ⛰️

[alerque]

I ended up with a similar situation before, made ever worse by the fact that it was a breaking change. The generated release notes not only had a giant BREAKING CHANGE warning, but also a revert for it. These are definitely things that should cancel each-other out, whether automatically or manually.

[orhun]

I think supporting sha in commit_parsers is a good start so I implemented that in #385 - feel free to have a look / test it out.

About detecting revert commits (i.e. cancelling out commits), there are some pending questions:

• How do we know a commit is a revert commit?
  • Does git2 (i.e. git internals) provide any information about that?
  • Do we need to need to manually parse the commit body ("Reverts ... ") to get the SHA1 of the reverted commit?
  • Can this be offloaded to the conventional commit parser?

[alerque]

No, yes, maybe so.

As far as I know off the top of my head revert commits to not have any special meta data that can reliably be used other than parsing the commit message. It is not even guaranteed that they follow the commit message pattern, although being built into Git as a default message means a large portion of them will follow it. Only some weirdos like yours truly sometimes edit the messages with more info.

Revert {{ original_message }}.
This reverts commit {{ original_sha }}.

The pattern you probably want to search for is not even the first line of the subject "Revert" but the "reverts commit " bit from the full body.

[orhun]

The pattern you probably want to search for is not even the first line of the subject "Revert" but the "reverts commit " bit from the full body.

Yeah I think that should be easily parseable.

Another question is how would config look like if we decide to skip revert commits and remove reverted commits from the changelog? Something like the following maybe?

[git]
include_revert_commits = false

Or even better, we can combine this with #85:

[git]
# commit types to skip as default, possible values are "merge" and "revert"
skip_commits = ["merge", "revert"]

Also, does enabling this automatically cancel-out the reverted commits? I guess yes.

[schoetbi]

Thanks for implementing the issue to ignore commits by adding the SHA to .cliffignore. This works very well.

Maybe a revert of a commit can be detected if a commit follows in the history that:

1. Is a revert-commit. Maybe defined by adding a parser like { message = "^[Rr]evert", revert = true }
2. Has a potentially short SHA in the body that was seen previously in the history

If this is not enough security, one can match the commit message with a regex defined in the parser to get the SHA as the group SHA.

{ message = "^[Rr]evert", revert = true, pattern="This reverts\\s+(commit)?\\s+(?<SHA>[a-fA-f0-9]+)"}

The text is somewhat defined here, so the pattern could be defaulted to the above without explicitly defining it.