4 ms·
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
by crabmusket 11mo ago
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 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 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.
- Aplikethewatch 11mo agoThis 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.
- crabmusket 11mo agoBest of luck! A couple of clarifications as I was writing from the train and didn't do a second draft: By "backwards" I meant to suggest, have the LLM critique a commit message you wrote. Have it point out vague language, weasel words, generalisation and marketing terms. The wiki article is good advice for writing in general, not limited to LLMs.
- crabmusket 11mo agoMore 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-prs-and-stacking/ https://crabmusket.net/2024/thoughts-on-git-commits-branches...
- js2 11mo agoI'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 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/1940a02dc1122d15706a7051ee47e73f329fb4f7 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/8f32a5a6c050766bfa2827869ec9116cebd0eb9b https://github.com/git/git/commit/8f32a5a6c050766bfa2827869e...