Show HN: Build the habit of writing meaningful commit messages

Meaningful commit messages are meant to be read later and be useful. I'm not going to read through 8 sentences of generated slop, would rather look through the diff.

Obligatory "show me the prompt" https://news.ycombinator.com/item?id=39374249

It probably depends on the codebase, but I find the best motivation for writing solid commit messages is reading commit messages. Tools like gitlens make this really easy.

Almost daily, I use commit messages and history as part of understanding why a decision was made, why a seemingly obvious alternative wasn’t chosen, etc. seeing the commit title on every line, and hovering to see the full message has become a core editor feature for me.

It’s kind of like testing, the more I do it, the more I want to do it because the value is so consistently reinforced.

There’s nothing like being able to track down exactly why a decision was made 6 years ago in a part of the code base you are struggling to understand written by someone who left before you joined the team.

YOU should be writing your commit messages, not an AI.

You can always generate a new commit message (or summary, alternative summary, etc) down the road with AI. You can never replace your mind being in the thick of a changeset.

If you are interested in writing better commit messages on your own, Google's advice makes for a good starting point:

https://google.github.io/eng-practices/review/developer/cl-d...

https://github.com/arpxspace/smartcommit/commit/cc677f7bd210...

This is just a complete braindead commit. Without looking at the code I could probably take 5 minutes to make sense of the commit message, being intrigued something interesting or important is happening. The message is massively over the top, it has way more text then actual code changes. It wastes time.

I am not against AI as a helper in various places. But if possible it should be an opt-in tool if deemed useful. If someone wants to get a summary about a non trivial commit, that can be useful. Even better if the committer writes about the intentions and reasons for the commit, so an AI could match those with the actual code. Don't reiterate whats happening in a patch. Give the meta that isn't there or less obvious. Please.

Core AI model interaction is here https://github.com/arpxspace/smartcommit/blob/main/internal/...

It is fun you have to pre-prompt with: You are an expert software developer.

> strictly enforces the Conventional Commits specification (feat, fix, chore, etc.).

Nope. Waste of bytes in my commit message header that are better done by git trailers.

Otherwise, I love the idea of the tool. I personally try to answer “why does this commit exist?” when I create commits.

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.

I was expecting a tool like this to exist. Kudos for actually caring about commit messages. As you can see from some of the comments here, there's a growing cohort of developers who simply don't, which is a shame.

I like the implementation, and how it asks you questions to get you to answer why a change was made, instead of making things up, or simply regurgitating what the code does.

I still wouldn't trust it to be accurate and would have to review it, and I personally dislike the default "LLM style", and I wouldn't want to read these messages or subject other people to them, so I won't be using your tool, but thanks for building and sharing.

I'm assuming the commits in the repo were generated with the tool itself. In that case, commit `cc677f7` has a (in my opinion) terrible commit message. It starts out with a listing of stuff I could just as well read from the patch. It then contains another list that tries to explain the why, but it ends up being useless fluff like `The full path specification in `go build` was redundant given the context of how Go modules are structured.` and `streamlining the project structure and reducing unnecessary directory complexity.` which tells me exactly nothing about why those changes were made.

It generates a whole lot of text that makes me none the wiser as to why you wanted to do any of those changes. It feels like a robot trying to justify the changes post hoc. Which it of course is, so that's understandable.

Don't take this comment as rudeness BTW. It's cool that you're making a fun little tool. I'm assuming you care about writing more useful commit messages, so I thought I'd give you some feedback on that part.

All my commit messages are a mess and I spend the time that I have designing and writing code, not figuring out how to make the commit message look pretty. That's what merges are for. I don't see the value of this tbh. Just pedantic time wasting.

ok, but did they have to make commit message required, or is there a way to disable it? i think of git as checkpoints, nothing more. the day i have to explore history is the day i quit.