Asking people to fit a meaningful description of the change into 50 characters is silly, and it's IMO the reason why so many of them just write "fix bug" and call it a day.

Someone else has posted the Google guide for CL (change list) messages, but let me boost the signal: https://google.github.io/eng-practices/review/developer/cl-d...

This is, I believe, still the best guide out there. When I'm coaching juniors, I recommend this guide, over the opinionated and outdated git "best practices" and I think the results are much better.

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 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.

This was a delayed project running out of budget and everything had to be completed within a few months. However, the management in it's infinite wisdom also did a complete source code/issue management platform change.

The person who did the repo migration went with the default settings. (I believe this was the case. I forget the details. I would also only half blame the person because everything was rushed)

Everything up to that point was committed with "Made by so and so bot".

This was way ahead of Google was allegedly committing "well over 30%" of code by AI. I witnessed the true pioneers in this space.

[1] https://pages.cs.wisc.edu/~remzi/Naur.pdf

> For the love of clean code history, let's remember we're not monkeys banging on keyboards; we're educated, civilized human beings.

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.

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

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

The act of composing a descriptive and concise commit message compels the programmer to transition from the task of "path-making" (writing code) to the intellectual work of explaining the process, which is necessary to grok the change completely.

Reviving the theory of an existing program is a difficult, cult-frustrating, and time-consuming effort. When theory-building is neglected, we lose the intellectual foundation that dictates the program's purpose and design, trapping future maintenance efforts in a costly, confusing cycle of trying to deduce intent from artifact alone

That might indicate an underlying problem that can’t be fixed with AI. ;)

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.

You don’t need 98% of commit messages ever again.

Yes when you need those 2% most likely it is for important reasons but usually not so important to make all the other mulled over.

Honest to God, this would discourage frequent commits.

Which will lead to a lot of work not being committed.

Thoughtful messages are for PRs.

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

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.

It baffles me how people think git log reading like a novella is a good idea. It’s not, because a cherrypick or merge can/will/should overwrite whatever clever garbage you put in there with its own message. Are you going to summarize Q4’s battle with scaling in a paragraph on the sprint merge to master? No. No you aren’t.

So, while I’m against commit messages saying “fixed”, obviously, I’m equally against a “conversation” in git.

If you have engineers on your team that are anal about commit messages, ask them to be as anal about features and teach them to git diff.

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.

This has nothing to do with self-documenting code. On the contrary, in fact, if I have to resort to checking git history that means the code is not self documenting.

From that description I thought it was going to generate the message directly from the diff and the message not being what you thought it would be would be a signal that the code isn't self documenting.

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.