Enhancement: (optionally) print commit messages and how Knope interprets them

[BatmanAoD]

This is something I've noticed semantic-release does, which I think would be helpful for understanding any surprising behavior (e.g. an unexpected version bump).

The idea is that knope would print the first line of each commit message it considers, then whether the message implies a version bump of some sort.

This could either be the default behavior or behind a command-line flag.

[dbanty]

This used to exist as an undocumented feature for my own debugging purposes 😅. You’re right that we should probably add a —verbose flag or similar for a stable, user-facing version.

For now, I think you can get an ugly version by setting the env var RUST_LOG=debug

[dbanty]

I've got a draft version of this going, you can check out a sample output here. I'd love to know what you think and if I can clarify that format at all 😁

[BatmanAoD]

Nice! Here are my suggestions:

• Include the initially-observed version. This would help with debugging (or at least recognizing) weird situations like Unreachable git commits are used for Go module version determination #505.
• What part(s) of the commits are printed? I see you have some BREAKING CHANGE example commits, but those are footers, right? I think in those cases it probably makes sense to include both the top-level "summary" line and the BREAKING CHANGE footer.

Otherwise it seems perfectly clear!

[dbanty]

Done! The formatting is pretty ugly, but I think it gets the job done and hopefully people won't have to stare at it for very long 😅. If you encounter any more pieces of info you wish it'd spit out, let me know and I'll happily start instrumenting more places.

[BatmanAoD]

Thank you! The formatting is fine, I think.

I'm now realizing, though, that the key piece of information I'm missing when I encounter "weird" situations is: why is a particular commit included in the set?

I'm currently looking at a situation where Knope caused 4 major releases in a row (when none was intended), and it appears that for some reason Knope is including commits going back through the last many releases. So the most useful thing would be a commit-traversal graph (similar to what git log --oneline --graph shows), and if the commit is tagged but doesn't cause the traversal to stop there, some reason for not considering that commit to be the "last release".

The four-major-releases sequence looks like this, using git log --graph --oneline to demonstrate that this history is purely linear:

* c89b27f (origin/main, main) chore: prepare release 5.0.0
* f04bea2 chore: prepare release 4.0.0
* 1baa508 chore: prepare release 3.0.0
* 87be05d chore: prepare release 2.0.0
* cf5aa4b (HEAD, tag: v1.0.3, tag: golang/v1.0.3) chore: prepare release 1.0.3
* a439139 fix: change how Knope updates Cargo.lock

When I use --verbose, I see a loooong list of commits going all the way back to a pre-1.0 commit that actually was breaking. But I have no idea why it's not stopping at any of the release-commits listed above, since the cf5aa4b doesn't have any direct parents other than a439139. (In fact, the history stays linear across 9 more releases before finally encountering an old merge commit. Additionally, I have no idea why the Knope runs that created 1.0.1, 1.0.2, and 1.0.3 didn't go further back in history.)