first — let's grow my twitter, so i can tell about my inventions quicker and make the world even better place (or not, idk)
I've been struggling making commit messages since 2017.
When you think of a commit message — you switch context from writing code. When you switch context — you waste time. Wasting time is lame.
I usually made 1 line commits like "amends", "fixed bug", "refactoring", "refactoring 2", "final refactoring" and then tried to come up with a good general message when merging a branch to production.
It has changed with THE FIRST AI REVOLUTION :)) I mean all this GPTs..
Two weeks ago I open-sourced OpenCommit. It can answer WHY the change was done if you change model to GPT-4 in settings! Insane.
The lib uses conventional commits convention which makes commits meaningful. You can also turn on GitMoji setting if you like. And select different languages and many other features (I got 12 PRs so far)
Simply install it with npm:
npm i -g opencommit
After installing type oc and hit "Enter" in a terminal:
oc
If you want OpenCommit to be used by your IDE do:
oc hook set
That's it.
For more features read the docs.
you may follow my twitter or not
btw, i have one more great tool for making GPT write extremely accurate code for you https://dev.to/disukharev/aitdd-ai-cli-for-tdd-you-write-the-test-ai-makes-it-green-32bn
Top comments (69)
This is very very BAD!!!!
Don't do this! If you do this you are missing the point of commit messages!
I think YOU are missing the point of GPT -- I've pasted in code and asked it to summarize and add comments, and it's done a much better job of summarization than me. You are severely underestimating AI if you think it can't summarize the gist of your code changes when committing. And if the changes are that confusing that AI can't understand them, that's saying something about your code.
Through your comment, you demonstrate that you are missing the point of the commit message. You are not supposed to summarize the changes. You are meant to state WHY they were made in the first place. WHY were they necessary. Was there a business need? Was there a bug? The changes are already obvious from the diff.
Your prompt for the description is "Add a short description of **what **commit is about after the commit message. Don\'t start it with "This commit", just describe the changes.". This is a what not a why.
Say you are adding a bounds check to some operation. The commit message probably shouldn't be "Adding bounds check". It should probably be something like "Fixing overflow bug CVE-xxxxx" thereby explaining why the change was needed. This requires a lot of context which the AI is never fed. When the AI will have that context it will just pick up tasks, make the changes and commit by itself without human intervention.
Commit messages that describe the what are of course still better than "First commit" "Second commit". If you are doing microcommits to your local repository and there is no individual "why" than this may be useful. With microcommits you are essentially using version control as a more powerful undo button. But such microcommits should be squashed before merging and the commit message should state why the change was made.
100 percent, the idea is to get feature to code traceability. The actual changes can be reviewed within the commit anyway.
edit: noticed you posted this same article 3 times under different titles.
isn't feature to code tracebility provided by ticket number though?
yes exactly, depending on the issue tracker embedding the code in the commit message and a description for feature/feature part that's been developed, will let you pull the relevant commits for that feature from the tracker.
Commit message should explain why the code is changed, not what was changed.
That should be easy. Dima just needs to update a prompt github.com/di-sukharev/opencommit/... and ask it to explain why commit is needed
it actually has config
description=true, so you can see the WHYAgain beside the point. The commit message should only be about the reason for the change.
If you think having the 'what' in the message and the 'why' only in the description, you don't understand communication, collaboration, documentation.
The sad truth is that this will in fact get used. There will be countless repositories that will be infected by AI in various forms because who has time when KPIs must go up?
Eventually people will skip analyzing that what the AI spits out is actually the intended code as long as it compiles and appears to work.
Eventually people will use AI to generate unit tests even if that is missing the point of unit tests. Unless you are writing unit tests specifically with the goal of refactoring an old code base piece by piece, AI written tests are worse than no tests because tests are meant to test the intended behavior not that the implementation does what the implementation says it does.
And people will use AI for commit messages thereby duplicating the information in the diff instead of explaining why a change was made in the first place.
KPI must go up. Boss no care about tech debt.
Note that this is not an attempt to dismiss this project. It is an expression of desperation at the precipice of the Eternal September we are on. AI will destroy interpersonal communication in all forms not by being bad but by being good enough and people being cheap or lazy. Commit messages are just a form of interpersonal communication.
Happy to report that my company is not like this.
But yeah I get your point.
I think having AI write draft for the commit message where it adds a guess about why that commit should be included. However, you cannot use that to replace developer communication.
The commit message should be about why the patch is included and it may also contain what only for the part where it is required for context. In addition, you can include summary level what if you feel that it improves understanding of the patch.
However, AI generating commit message which only contains what the patch does is totally useless. This is because such "data" could be re-created while inspecting the patch in the future. And the future AI generator will output better description of what than you can currently have! As a result, if the AI generator to describe what is only used while creating the commit, you'll be locked to historical inferior AI implementation forever.
Let's take a commit from the git/git repo:
github.com/git/git/commit/8b95521e...
Do you think that commit message describes the contents of the diff?
Or does it describe why that commit is needed in the first place?
Sure, not all commits need equally long descriptions but I've written a lot of patches for our in-house system where the commit message is longer than the full diff.
And the rationale for having this information in the commit:
(1) You can link to the issue tracker from the commit message but nobody wants to read the whole discussion in the issue tracker to understand the commit. Basically the commit message should explain the rationale that can be understood after reading the whole issue tracker ticket from start to end.
(2) Whenever you actively maintain a piece of software for a long time, you'll find that the max number of consequtive lines in a source file that originate from any given single patch gets smaller and smaller. When the source is 10 years old, nobody can remember why some specific edge case was handled the way it was implemented 6 years later. If you have a commit message like the example I linked above, you can pretty quickly get understanding of the reasons why the code is written like it is. And if might be that you'll notice that the new issue you're working on is caused by the fact that it's a new corner case that was never considered for the original change.
(3) Having the most important data in the commit messages allows understanding the code much much faster in the future. Sure, you could have commit messages with nothing else but a link to the issue tracker. But that would be really tiresome to read after the fact 6 years later when you have to understand the code better to fix some complex issue. With proper commit messages, you can use git blame to get line-accurate explanation for the code. And note that this is much better than maintaining comments in the source code because git will automatically get rid of documentation that will not match any currently existing code. Example case:
github.com/git/git/blame/8b95521ed...
Note how every
if (...)clause comes from different commit. Not all those commits have equally good commit messages to the one I linked at the start of this comment but this example should give you some idea about why good commit messages matter.If you truly believe that AI generated commit message is all you need, you should simply commit your code with a commit message "to-be-filled-by-future-ai" because future AI will create even better commit messages than the current AI. As such, it's waste of resources to run that inferior AI system now when you could be running the improved future AI system instead to generate the missing commit message when you actually need it, right?
Some additional examples from recent git/git commits:
github.com/git/git/commit/a8bfa99d...
github.com/git/git/commit/7ce4088a...
github.com/git/git/commit/15a4cc91...
github.com/git/git/commit/28d1122f...
github.com/git/git/commit/e2d003db...
Note that the last one is 2-line change to the source code but it adds 4 line code comment and about a page worth of commit message.
So if you trust authors of the version control system you're using for a good example, maybe assume that these are good examples?
Totally agree with this user -> @mtrantalainen If a junior dev commits a message about the files being changed it will get rejected. We know what is changed because of the commit.
"if you think it can't summarise the gist of your code changes". What was it in @alexvoda's comment that made you assume so?
omg again.. very bad :)
pls tell me — have you tried the tool? using GPT-4 solves the "WHY", no so strong like the examples above, but its impressive anyway. You can tune the code to solve whatever you want, PRs are welcome <3
A clean message is a message that communicates only what it should. Which is, why was this changed. Not how.
The diff is the description of changes. The commit message is the reason for the changes. A better use for this technology would be to supplement viewing diffs in your version control interface to give a summary of the diff
Oooo, now that's an interesting one that would actually be quite useful. It analyses the diff and gives you a summary of the key changes. I'd give that a try for sure.
Hey I'm building a platform that does this. Would you like to try it? It's pacepeek.com and you can email me at r@rasmusmultiverse.com
We use concept of Why when the commit make changes
But what if it just add a new feature or the project is still in the beginning and you just adding new code blocks , is it ok to use the descriptive commit in this case?
Definitely checking this out, thanks for sharing. I don't use Twitter any more though - feel free to find me in the Fediverse ;-)
The demo images still seem to only write commit messages that describe what changes. Commit messages should describe why the code is changed. "What" can be read from the diff or stat.
you can turn on the config
description=trueand see the whySo the AI knows why you made the change? Impressive.
you can try with:
and then just run
ocevery time you want to commit smthDoesn't that defeat the purpose of the whole thing?
i dont get you point, sorry :)
If you have to enter a description manually to give meaning to the commit about the purpose of the changes (which the AI could never know), then what is the point to having an AI write a message based on what changed in the code?
People should learn to write decent commit messages themselves, as a courtesy to themselves and others.
The commit messages should describe the intention behind the change. Would be impressed if the AI were able to distill that.
Would not hire the person who wrote the commit messages under the "Before" section.
how to edit message? if i need to change some text of the commit message
try
oc hook setand turn on a setting toopen git commit message as a file to editin your IDEI'm quite a newbie and when I type the hook command I get this error:
oc hook set
┌ setting opencommit as 'prepare-commit-msg' hook
│
└ ✖ Error: EPERM: operation not permitted, ... (my git repository)
Can you help me solving this issue because I can't edit the commit message.
By the way, this extension is amazing, thank you
try
sudo oc hook setIt does not work
If you using windows you have to run vscode as administrator to make it work
I'm a big open commit user, can really recommend this stuff.
Saved me a lot of time on writing commit messages
great to see you here ;)
First of all no good dev commits like the "before", secondly, I doubt GPT is able to understand the scope of a task and the project. The commit message should be a meaningful short message to understand what was done in the scope of the task/project, and not just list all the changes, which can be observed by checking the diff.
mention Linus here pls :)
I just used it and it's awesome except one thing that it's NOT FREE 🥲
ChatGPT model is really cheap bro — it's like $0.15 for me each day
I have added this post and I am very excited to looking forward to using this as well.