Print summary after checking a commit

[orhun]

Hey there! 👋🏼

I'm considering to switch from cocogitto to committed in a project since I find it more elaborate for checking commits. One thing that I'm missing is the commit summary in the cog verify output:

$ cog verify 'test(what)!: Aaa'
BREAKING CHANGE - Aaa (not committed) - now
        Author: Orhun Parmaksız
        Type: test
        Scope: what

Compared to committed:

$ committed --config committed.toml --commit-file - <<< 'test(what)!: Aaa'
# nothing

This summary is especially useful when being run with a pre-commit hook and helps me visualize the changes in a branch better.

Would it be possible to add something like that to committed as well? Thanks!

[epage]

One part to figure out is how this all works. You give an example with --commit-file - but that isn't the only way to run it and in CI its generally run across a series of commits. What would be shown in that case.

Another is fit. cocogitto is an all-inclusive tool, focused on conventional commits. committed is a linter that includes conventional commit support. From that perspective, I'm trying to understand how this fits in and what is the general principle for what should be shown in a summary.

[orhun]

CI its generally run across a series of commits. What would be shown in that case.

In the case of cocogitto it shows the summary for each commit when there are multiple ones that are being checked. In our project we run this as a commit hook so it makes it easier to spot what has changed in a branch and whether if there are breaking changes. I think committed can also do the same: print a summary for each commit.

committed is a linter that includes conventional commit support.

This is a good point. I think including some general information about commits (e.g. type, scope, is-breaking, etc.) when style=conventional would be a good start for this.

However, I see that printing a summary might not be fully aligned with the goals of committed. Either way I would appreciate this feature!

[epage]

So it sounds like you are wanting something more like cargo release changes which is also a little smarter in that it assigns commits to specific packages based on their cargo publish --list (which can miss things when files are deleted).

The use case you gave is unrelated to linting. To support it, I feel like we should probably grow beyond linting to being a more general purpose commit message tool. I'm a little hesitant to taking on that increase in scope, especially as I don't have a good vision for what all would then be in scope.