I applaud your desire to write better commit messages and not be lazy. Not every commit deserves the attention, but being able to turn on "I am definitely going to leave a precise record for the next person to see this diff" is a great skill to have.

However, I feel like your approach here is a little backwards. By getting the AI to come up with the commit messages, you're actually removing the chance for the human, you, to practise and improve.

I'm a real fan of Kahneman's "thinking fast" and "thinking slow" paradigm. By asking the human to review and approve the commit message, you're allowing them to "think fast", instead of doing the challenging, deliberative "thinking slow" of actually writing what you mean.

While getting the LLM to ask you questions about what you did and why is better than just one-shotting the commit message from the diff, it still lets you reply "reactively" and instinctually, using your "fast" gut thinking, instead of engaging the slower attentive processes required to write from scratch.

Now there are a couple of other posters here critiquing the commit messages in this repo's history. I think that's fair, but by your own admission you are learning, and this is a small and new project! Probably most commits should be along the lines of "getting a thing working", not essays about the intricacies of character encoding:

https://dhwthompson.com/2019/my-favourite-git-commit

But the commits we can see are already demonstrating some of the pitfalls of LLM generated language.

From a recent commit,

"This update enhances user interaction by explicitly addressing scenarios with large diffs, directing users towards feasible actions and maintaining workflow continuity."

This comes after a detailed breakdown of the diff. It is too vague to stand alone without the preceding detail (e.g. 40k character limit) but also doesn't explain them. Why 40k characters? Why any limit at all? Words like "enhances" and "feasible" are filler - be concrete instead.

This article on wiki has fantastic advice about ways that LLM writing fails, more along the lines of what I've just pointed out:

https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing

Writing well is hard, never "effortless" as your readme advertises. Sadly, good results have to come from hundreds of hours of hard and uncomfortable work. Truth is rare and precious and difficult to come by, and even when we glimpse it, turning it into words is a whole nother story. I hope you can continue to develop this tool to help you learn and train your own writing, rather than avoid it.

More drive-by criticism of your commits, meant in a sincere attitude of helping you learn.

As best I can tell, lots of your commits seem to be including several unrelated changes.

This means commit messages become longer as they have to explain more things, and they also end up explaining the diff so that you can fit more on one page.

I'd suggest getting in the habit of making coherent commits with one change each. Some changes will be trivial, and the diff will be self explanatory. Then you can save your writing effort for commits that are challenging.

On the other hand, if I'm wrong and many changes to have to get bundled, then the commit message would be a good place to explain why.

I wrote more on the "primitives" and what I think of as the "physics" of commits here: https://crabmusket.net/2024/thoughts-on-git-commits-branches...

I'd rather have that commit message than one that doesn't explain anything, but it's a bit verbose to my taste because I don't really care how he discovered the issue. I really just need to know what and why.

So let me link to my favorite author of consistently excellent commit messages, Jeff King on the git project itself:

https://github.com/git/git/commits?author=peff

To pick just one, here's a well explained single-line code change. It's subtle, so besides the excellent commit messages, he also adds a comment and a couple tests:

https://github.com/git/git/commit/1940a02dc1122d15706a7051ee...

Another example with an even greater ratio of explanation (10 paragraphs) to code (partial line change):

https://github.com/git/git/commit/8f32a5a6c050766bfa2827869e...

> Probably most commits should be along the lines of "getting a thing working", not essays about the intricacies of character encoding:

I'm not a fan of that commit as a commit, although it would make a great start for a blog post. The explanation of how the issue was tracked down, is not helpful in understanding what the issue is. On the other hand, while the author describes finding (and replacing) a non-ASCII character masquerading as a space, it would have been more interesting to know what character it was.

I agree that explaining the "why" is useful, but in this case I don't think it deserves much more detail than "ensure the file uses only ASCII characters to avoid a text encoding error while running tests in this specific manner". (I guess I can also see the argument for showing the error message for later searches, too....)

This is amazing, thank you! Will definitely take this on board for the next iteration of this tool. I wholeheartedly agree with the perspective of:

> develop this tool to help you learn and train your own writing, rather than avoid it

Will be striving for this for sure.