I don’t know why it’s so hard for devs to stop for 30 seconds and answer the question “why does this commit exist?” That’s the question you’re going to ask when you find the commit in `git blame`, so just answer it.

I read on here someone saying to think of a commit message as starting with “When applied, this commit will…” and that helped me a lot coming up with good messages.

Needing a LLM to figure out what your staged work is doing is a real red flag.

Official Git docs say commit messages should be in present tense and imperative mood:

> Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.

• GOOD: “Fix app sending unnecessary requests"

• BAD: “Fixes app sending unnecessary requests”

> Another best practice to help you write good Git commit messages is to use imperative verb form. Using imperative verb form ensures that potential verbs used in your commit messages, like “fixed” or “updated” are written in the correct tense to “fix” and “updated”.

I insist on present tense, imperative mood in every codebase I work on. The Git log makes a whole lot more sense when it can be read this way.

For anyone wanting to read the specific document:

https://git-scm.com/docs/SubmittingPatches#describe-changes

To be clear, the document does lead with:

> Please note that this information is only relevant to you if you plan on contributing to the Git project itself. It is in no shape or form required reading for regular Git users.

In spite of that qualifier, I think that the directions offered do apply extremely well as general guide, too.

> Your code may be clearly written with in-code comment to sufficiently explain how it works with the surrounding code, but those who need to fix or enhance your code in the future will need to know why your code does what it does. [...] You do not have to say "Currently"---the status quo in the problem statement is about the code without your change ...

That's a fine guideline for the title. The message should be way more freeform.

I like to imagine myself writing an email to one of my colleagues about why we should be doing this change. I do not assume prior knowledge of my intention, but do assume contextual knowledge about the system.

There are a lot of these tools. I use AI Commits. https://github.com/Blarc/ai-commits-intellij-plugin

Feature suggestions:

* Emit validated conventional commits. https://www.conventionalcommits.org/

* Create templated PR descriptions from multiple commits.

* Take the existing diff into account when you do a git amend.

Aider’s /commit is quite good.

Tools such as this should not be used. The generated commit messages are all noise, no signal. The LLM can not possibly describe why a change was made, and it can never describe why a corresponding more obvious change was not made.

Should you somehow find yourself in a situation where the above does not hold, and you really want the LLM description, it is still bad design to run the LLM on commit. LLMs will only get better over time. In that case you should not use commit messages but run the LLM on "git log" instead.

Just as it uses heuristics to show moved files it is also the more suitable place to summarize the diff, if that is all you place in the commit message field anyway. At that stage it has potential knowledge of the future as well, with that added context the summary might actually be useful ("this functionality is later replaced with ..").

It reminds me of the trend of companies now requiring cover letters as they can use an LLM to summarize them. Now many job candidates are using LLMs to generate their cover letters. So LLMs are now trying to convince other LLMs of a human's fitness for a job. Between the job seeker's prompt and what HR sees from the LLM's summary, lots of noise is passed around and what little signal is there is likely lost.

I really don't like this as - similar to many comments here - it feels like an attempt to outsource the essence of programming and at best give you a pseudo-code summary of your changes vs. a valuable description of the intent.

But if it tamps down the holy wars of "pick a git comment style; be a dick about it" maybe there's value?

"A good commit consists of multiple elements, but at a minimum, it should have a well-crafted commit message. " I'm not sure I accept this premise. Just a few words is all that is needed. Anymore and it becomes this OCD novel you are writing that doesn't actually help the code base later. Git log -p is where you really look to see what the commit did, not a well crafted message.

The diff will tell you what's changed, but it doesn't tell you the "why" of the change. A project should store that information somewhere; whether it's in pull request descriptions, issues/tickets, or the commit message, which is a perfectly reasonable choice.

I omit very obvious stuff from the git commit if it is visible in a diff, for example if I change "a" to "b", my commit message is not going to be "Changed a to b", but something more general, not too specific, that is what the diff or source code is for.

And as someone said, I often include the "why".

A well-crafted commit can have a few words or five paragraphs. A few words will never be enough for a non-obvious change.

Some people might then say “use code comments”. But those inline comments won’t work when you have five years of source code change and those three lines deserve a cumulative seven comments.

A code comment can tell you why the code is the way it is, but it shouldn’t tell you why it changed. That’s what commit messages and/or PR descriptions are for.

I meant "long commit messages"* in my OP

> Just a few words is all that is needed.

But then this wouldn’t be a good application for a LLM so clearly that cannot be /s

Use this bash script https://gist.github.com/davidesantangelo/ce7424e68b7d1e7903e... and paste the result into your favorite LLM with a simple prompt "write a git commit message markdown from this <result>"

This doesn't answer the crucial question of why the change you're committing is necessary.

Don’t waste people’s time on messages created from diffs.

What I don’t like is using AI to write commit messages outright.

But this reviews the commit message. Which might have merit.

There are projects where the commit messages are reviewed. And they may have guidelines written in prose for that somewhere. If the AI can be tuned on that then great, might save some human review time.

I'd recommend following the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) guidelines for writing the commit messages.

I’d recommend against it. The most prominent aspect of it, the “feat:”, “fix:”, etc. labels, are better done with git trailers. The “module” that appears in parens could be another trailer, if you so desire. You don’t consume valuable bytes in the short message and you lose nothing in terms of search-ability. You could probably even use the trailer values to reconstruct conventional commit format if you really need to see it in that way.

Scope labels are great, but I'd just recommend being super freeform with them. They can help encapsulate what part of a codebase is primarily impacted by them.

Git trailers are neat, but ultimately suffer from a UI issue: most people are using interfaces to git that don't use the plumbing, and they put all the important info in the first line (and sometimes have a frustrating cutoff of 50 characters) and git trailers are considered a remnant that gets no special handling (if you're lucky, the Co-Authored-By trailer has special handling, but that's about it).

If you're trying to quickly conceptualize why the history of a file is the way it is, then being somewhat consistent with scope labeling helps a lot.

In practice, the style will just be different depending on the project. A hobby project doesn't need a hypervigilant git history, given you're usually just using git as a special save button. A rebasing fork will probably want to structure it's commits more on a per-patch basis (since they should be kept on top of all other commits), so most conventional advice doesn't make sense (since the git commit in this situation also acts as the code comment for the patches; you're usually trying to keep patches as small as possible for ease of maintenance). It's when you get professional that you'll want a commit style.

> Git trailers are neat, but ultimately suffer from a UI issue: most people are using interfaces to git that don't use the plumbing, and they put all the important info in the first line (and sometimes have a frustrating cutoff of 50 characters)

It’s not git’s fault if you choose not to use git(1). Trailers work great with it. You can use other tools that claim some level of compliance with git, but you do so with the understanding that YMMV.

I'm just going by the practical reality here; I personally do like using the git commandline, but the reality is that most people are using Git from forges like GitHub and terrible UI programs like, well, GitHub Desktop, which do both of these things.

Ultimately git is a tool for version control and software collaboration, so what you end up doing should encompass the tools that people use. It's easier to find a compromise than to hardline on a position that requires a lot more upfront work (it's much harder to switch people off of software that they are familiar with than you might expect.)

If you limit your quality by what the lowest common denominator tool does you will guarantee that your process deteriorates until you're all just rolling around on the floor gurgling at each other.

The answer to "my tool doesn't render trailers" is not "let's waste the short message" it's "then don't use that crap tool"

I won't recommend it specifically, but I recommend to have a standard. I prefer a standard that I don't like rather than a not having a standard. Other options that I remember:

- The kernel patch descriptions: https://kernelnewbies.org/PatchPhilosophy. Used by the repository that Git was created for (the Linux kernel) and Git itself;

- Gitmoji: https://gitmoji.dev/, similar to conventional commits but using emoji

Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that.

You don’t need a standard for everything. If standard means a machine-readable format.

> Personally we may like them or not. But again, even though I don't like it, I would a history with "<bug emoji>: do foo in bar" instead of a history with a lot of commits only named "fix", "now it works" and things like that.

It is good to have standards which will disqualify low-quality commit messages.

Why do you recommend it? I think it looks bad and doesn’t provide enough value for all the space it takes up.

Having a standard is better than having no standard. If you don't like conventional commits probably you have a commit guideline that everyone in your team understands and follows and that is better suited for you case.

So, it is not for you anyway, as the problem it solves is already solved for you.

I'll second it - consistency is better than perfect

Despite the confusing copy here and on the landing page, the tool appears to be a commit message linter not a generator. Which seems useful. In fact, I was thinking of building something like that for internal use. Thank you for sharing.

Don't listen to the negative comments. I think this is great, good on ya for building and releasing it.

Sure you could improve it by emphasizing the 'why' of the commit, but what I see is a great start.

Also, a lot of commits are save point in nature (like if they will be squashed or rebased before merge/push), and the alternative for me is to name them "progress dump" or something because I don't want to look at the diff of an arbitrary commit just to come up with a sensible message.

Though for that I use the AI git message button in Cursor these days. But you don't need to be a noob vibe coder to find it useful.

The haters all have github repos where they've resorted to low quality commit messages at least from time to time.

Can I use this to rebase in a commit message higher up in the commit log without rewriting it myself?

It might be useful to decorate a repo that lacks commit messages with synthetic guesswork.

Sorry if I'm confused, cocommit doesn't actually generate commit messages (based on staged code)? It only analyses the previous commit message?

Ugh not where I’ve ever worked, no. That would get flagged during review.

you guys do code review??!

joking aside, its kinda hard to find places that actually enforce high standards for commits in my experience

It's a great addition to vibe coding: people who can't code and don't want to learn can now write commit messages they won't understand. Do we really need LLMs and AI slop to write a few sentences now? What's next? LLMs to move the cursor of your mouse because it's too hard?

Actually, it will be great. If I am disabled from the waist up, and I want to continue coding, I would love to be able to ask AI to do a lot of things that I think are too hard.

Do you want AI to "think" for you, or just a really good context-aware robot? This is definitely an attempt at the former.

Would "we" not realize this though? I don't care as long as things work. In some cases the source code has to be organized, with proper naming and so forth. I think by looking at either the end product and/or the source code, we could tell if the use of LLM was done by someone who does not know what he is doing, at least in some cases, vs. done by someone who does know what he is doing.