AI Commits – a CLI that writes your commit messages for you | Hacker News Reader

AI Commits – a CLI that writes your commit messages for you

github.com

60 pointsfeross44 comments

Something I learnt about good commit messages over my career was that the more useful messages don't summarize what is in a change, but why the change was needed. Usually everyone can quickly figure out what changed if the commit is of some kind of reasonable size, but why it was changed is lost forever.

That said, a lot of my personal projects that will never get published are just "foo" messages.

I personally try to always include at least a short explanation on why the change was done, unless it’s self-explanatory. But I’m under the assumption that most people don’t do this because they already have that info in a relevant issue or merge/pull request. Which I think is a fine approach, especially if you leave the relevant link or identifier to the commit message.

In my experience ticketing systems come and go, but the commit history remains forever (yay dvcs), so it's a good idea to summarize the why in the commit message - even if it's already also somewhere else.

Agreed. I usually end up writing the thing in at least one place besides the commit. Takes more time, but should be more future-proof as well. :)

The best advice that I got was to write commit messages as a letter to your future self.

This is super cool, but I also really hope people I work with don’t use it much since I rely on commit messages to tell me the “why” and other high level questions on the whole diff that don’t fit into local comments above a single line. If it is simple enough to be self evident it’s simple enough to include 1-2 words and not risk hallucinating a red herring IMO

This, the "what" in a commit message is close to useless, the "why" is what matters. Unfortunately developers really don't need another excuse to skip the "why" so I hope this tool doesn't get any traction.

"I needed to build a screen for my models" gets old

Hey, at least it doesn't put "feat:" or "<bug emoji>" at the front of the commit message!

Oh man that was a horrible time, when you get a project where dotting each file with a different emoji in github was some kind of work of art more important than the project itself.

It still happens today: https://github.com/carloscuesta/gitmoji

Probably stating the obvious here, but do not use this at work. At least if you work for the 99% of companies that would be unhappy to find out you've been uploading all their code to third-party servers.

You should be answering the question “why does this commit exist?” when you write your commit messages. You’ll be asking yourself that same question when you come across the commit via git blame or bisect later. Summarizing the content of the commit usually isn’t enough to provide that context.

I prefer to have both. First line — a short summary of changes, further lines telling reasons and relevant comments

I think it really depends on the type of project. An open source project is going to have different goals for commit messages than an internal corp project or a private personal project. I'm a big fan of conventional commits, but only in the context of a project that needs to generate a changelog so that users can quickly decide if they'd like to update. In that context, the why is totally inappropriate and should be part of a linked issue, not the commit message. But in a corp environment, it's really much more about preserving context so that future developers can figure out why something happened, so the why is super important. Corporate teams will have turnover and, when someone leaves, they're not going to be available to answer questions. And a private personal project is often just about using git as a checkpoint saving tool so that I can preserve known-working states. In that context, I'm really only interested in describing the state I'm preserving rather than describing what changed or why. If I ever decide to release it publicly, I'll rebase to hide the mess of my initial explorations anyways.

Not being able to adapt your commit message style to the purpose it's serving is overly dogmatic. I wouldn't use the same language or tools for every project, so why would I use the same commit message style?

But if it can be mechanized then why inlcude it in the commit log at all? Just run the tool post hoc if you're interested in what it has to say about a commit.

It could be interesting to see the differences between author and generated messages as per a sibling comment. But for the purpose of trustworthiness I think you would want the commit author to pull the trigger on the comment (It's pretty clear from recent examples in the wild that it's a bad idea to trust language models for correctness beyond the language itself).

The semantic difference between an auto-generated CLI commit message and the one the author writes would actually be a pretty good lint.

I've seen bad rebases where unintended stuff slips in that probably could be caught by this sort of thing.

I used to think commit messages were important. Now I don't, or more specifically I believe the importance should be shifted to ticket titles.

In the workflow I was introduced to all commits backing a PR get squashed and merged with the commit message for that merge being the ticket number and title of the ticket the PR resolves.

This creates an incredibly clean commit history that is easy to trace back to tickets and their associated work items (like product docs). It also frees coders from any burden of writing good messages as they progress.

I prefer this workflow too. Only issue is if we move to a different ticket tracking software.

Well, and finding out what the message #345 really means. I use file/line history a lot, it gets really useless with ticket numbers only. Yes, one could automate that to fetch the ticket description and display it. But the ticket description doesn't match the commit. It might for a simple bug report, but it doesnt at all for a bunch fine grained commits which together build up towards implementing a new feature. Might depend on the line of work, but having been there and done that: nevermore.

Both are important, imo. Writing good commits is useful for “showing your work” and breaking things down into steps. For example if I need to refactor a component when building a new feature, then I do it in a separate commit. Makes it easy to spin out a separate PR if necessary, and helps a reader understand why the refactor was necessary by looking at the next commit diff.

You can still write “fix” and “wip” commits locally, as long as you rebase them before you push your branch.

I also think that more commits when doing refactors help with history tracing once file renames get involved. It can be real head-scratcher to try to trace a function back through some commit that introduces a new feature + a whole module refactor. Even with “follow”.

There are a few issues with this approach:

- It becomes harder to change the issue tracking software. I used to work for a company that went through a few bug trackers, resulting in tons of older commits referencing an inaccessible bug tracker.

- It forces developers to switch from their IDE or git blame to another tool when doing code archeology. The last thing I personally want when trying to understand some code is more context switch.

- Not all commits have an associated issue. I sometimes stumble upon problems in the code that I fix straight away. Writing a good commit message explaining the reason is important because otherwise the context is lost.

Yep, mine is on its third bug tracker since I started (maybe more from before then), and third version control system. All the old cases are lost, but the repositories get imported to the next one and retain all their old commit messages.

Sounds like the approach that Gitlab advocates.

Yup, squash and merge is THE way to go. I've tasted the good life. I always tie a commit back to a ticket and go to the ticket/issue for context with squash and merge. There is so much rich discussion in it that commit messages don't compare.

This approach when merging in the GH UI, puts the ticket number in the merged commit (not a merge commit though). And the biggest advantage of this approach is there is NEVER a "revert the revert" situation when dealing with reverting. So easy and clean to revert because you aren't reverting a merge commit.

I get that "we can't change issue tracking software" but that is just something you gotta live with, and the advantages of squash and merge far outweigh this "possibility".

For what it’s worth, I hate squashed commits. I can’t count the number of times that I wanted to know the source of one specific change, only to be redirected at a git diff with thousands of lines of changes.

Ridiculous. That defeats the point of source control, which is partly to aid future readers, not merely track changes.

I’m happy your workflow works nicely for you, but I hope the mindset goes away.

Personally, I think it’s important to force push over your “bad commit” when it happens. That way you don’t generate dozens of WIP commits, and there’s no need to squash. But sometimes WIP commits are fine to let through. They inform other devs about what you’re experimenting with.

I feel that if you have thousands of lines of changes in one squashed commit, you're not breaking down work enough. IMO, each feature or bugfix should be on its own branch, and then all the commits from that branch get squashed during the merge to a develop/release branch or to the main branch. If merging to a develop/release branch first, then merges from there to main do not get squashed.

Something-something indirection.

You’re just saying that messages (or: what and why things happened to the code) should be moved out of the repository and into the issue tracker.

This is like me saying that wiki articles aren’t important… because we don’t use a wiki for documentation and just commit the docs in the repository. Yeah, sure. But most of your interlocutors were probably more concerned with the fact that things needed to be documented, somehow.

I'm usually pretty sceptical of this tech being capable of a net positive, but this seems like a pretty safe and suitable premise (as a writing aid)... Since you are only relying on the model for the language rather than a source of truth, instead the author can validate the correctness and adjust before pulling the trigger on the commit message.

The only place this falls down are for commits where the reasoning cannot be inferred and summarised from the code alone, or for reasons not apparent in the immediate code that require deeper understanding of the relationship between disparate code. The kind of information which is only in your brain, intent, these are the most important types of commit messages, and no language model is going to be able to help there... but for the rest, why not.

Last time I was negative to the idea. This time I’m conditionally positive: if I find myself in a project that mandates a structured style that I don’t like, like “conventional commits”, then it would be nice if a program could at least deal with the structured part on my behalf.

Need to take this all the way. Should be a dynamic service that annotates your already existing commit log whenever it's queried. Your "commit messages" would get better over time as the AI improved. Leave the statically persisted commit messages to the humans.

I used chatGPT to convert it from TS to Ruby: https://github.com/ZPVIP/commitgpt

Special thanks to Nutlope.

So, instead of writing “git commit -a -m ‘oops’” I can simply make another alias called “aicommit” to do it for me?

What we need is a CLI that does it the other way around: I write a commit message describing changes I want to make to my codebase. A CLI that is offline and familiar with my codebase cooks up:

(1) tests (2) features and or fixes (3) perhaps supporting documentation (4) perhaps even applicable build changes

It seems like what you need is perhaps a developer writing code for you? Maybe in exchange for money.

Haha, I am a developer. Do you know how many projects I’ve worked on where the tech lead said “thou shalt write a week’s worth of boilerplate cruft per each new feature” just to make sure the codebase adheres to the pattern? Anybody who does that and pretends they’re being “productive”… is hurting my feelings.

If I could do the work of even two developers, I’m definitely getting paid. I think software engineering is headed for a John Henry moment.

There’s a lot of room for AI in the commit process. In particular, I’d love a CI check that docs haven’t gone stale. A big issue with investing in thorough docs is that the systems they document can easily drift away from them.

I made something similar here:

https://github.com/programmarchy/git-gpt

Hardest part is writing the correct prompt. Your prompt looks better!

Is it time of the weekly thread for yet another tool that writes useless commit messages that completely miss the point of a commit message?

Code will be send to OpenAI.

Nope.

Honest question - do people actually look at commit messages seriously? For me it would be a nightmare to review by commit...Instead if you think of the smallest unit of work as the PR, you can just view all the changes and be done with it.

Not saying a commit message should be drivel but it can just be a simple one liner (it does help with Git Lens as you navigate code but that's about it).

Reply on news.ycombinator.com