feat(parser): support using SHA1 of the commit

[orhun]

Description

See #382

Motivation and Context

This PR makes it possible to use the SHA1 of a commit with commit_parsers.

For example:

# skip a specific commit
commit_parsers = [
    { sha = "f6f2472bdf0bbb5f9fcaf2d72c1fa9f98f772bb2", skip = true }
]

Another example:

# override the group of a specific commit
commit_parsers = [
    { sha = "f6f2472bdf0bbb5f9fcaf2d72c1fa9f98f772bb2", group = "Stuff" }
]

How Has This Been Tested?

Unit/integration tests.
I didn't add fixture tests since it requires more work to find out the SHA1 of the created commit and substitue in expected.md.

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly.
• I have formatted the code with rustfmt.
• I checked the lints with clippy.
• I have added tests to cover my changes.
• All new and existing tests passed.

[schoetbi]

Awesome that you implemented this feature. It really helps me! What I noted when trying this out is that the order of the commit parsers matter. If I placed the SHA skips at the very beginning, it worked. When I moved them to the last position in the list, it did not filter out these commits, even though the git hashes matched. Is there a reason for this? It seems to me that the parsers are processed in order and the first match is processed only because when I moved the parser for the grouping to the front, the SHA skip did not work. I did not check this in code.

Also, the SHAs should match, even if the casing of the letters is not the same as git delivers it.
These two lines should behave the same

commit_parsers = [
  { sha = "7ff168fbac5bf5dfc772e14e1ff23e62a338aab8", skip = true },
  { sha = "7FF168FBAC5BF5DFC772E14E1FF23E62A338AAB8", skip = true },
]

Since this list might get lengthy over time, it might make sense to add a skiplist file to the configuration. The skiplist file then contains all the SHAs that will be ignored.

[orhun]

Hey, thanks for testing it!

When I moved them to the last position in the list, it did not filter out these commits, even though the git hashes matched. Is there a reason for this?

It is simply because the commit_parsers are processed in order and if a commit is matched by a parser it can't be parsed by another one. There is a related issue here: #117

Maybe I can note that the order matters in the documentation, or even better, support multiple parsers to be used.

Also, the SHAs should match, even if the casing of the letters is not the same as git delivers it.

Good catch! Should be fixed in d698809

Since this list might get lengthy over time, it might make sense to add a skiplist file to the configuration.

Can you create an issue for discussing this feature? We can potentially have this configuration:

# cliff.toml
[git]
commit_parsers_file = "parsers.toml"

# parsers.toml
commit_parsers = [
    { sha = "f6f2472bdf0bbb5f9fcaf2d72c1fa9f98f772bb2", group = "Stuff" }
]