DEV Community

Cover image for OpenCommit: GPT generates impressive commits in 1 second 🤯🔫 (open-source)

OpenCommit: GPT generates impressive commits in 1 second 🤯🔫 (open-source)

Dima Sukharev on March 27, 2023

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 strugglin...
Collapse
 
alexvoda profile image
alexvoda

This is very very BAD!!!!

Don't do this! If you do this you are missing the point of commit messages!

Collapse
 
rkogan profile image
Robert Kogan

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.

Collapse
 
alexvoda profile image
alexvoda • Edited

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.

Thread Thread
 
rolfstreefkerk profile image
Rolf Streefkerk • Edited

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.

Thread Thread
 
dadyasasha profile image
Alex Pushkarev

isn't feature to code tracebility provided by ticket number though?

Thread Thread
 
rolfstreefkerk profile image
Rolf Streefkerk

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.

Collapse
 
mtrantalainen profile image
Mikko Rantalainen

Commit message should explain why the code is changed, not what was changed.

Thread Thread
 
dimichgh profile image
Dmytro Semenov

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

Thread Thread
 
disukharev profile image
Dima Sukharev • Edited

it actually has config description=true, so you can see the WHY

Thread Thread
 
joriswitteman profile image
Joris W

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

Thread Thread
 
alexvoda profile image
alexvoda • Edited

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.

Thread Thread
 
joriswitteman profile image
Joris W

Happy to report that my company is not like this.

But yeah I get your point.

Thread Thread
 
mtrantalainen profile image
Mikko Rantalainen

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.

Thread Thread
 
Sloan, the sloth mascot
Comment deleted
 
mtrantalainen profile image
Mikko Rantalainen

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?

Thread Thread
 
mtrantalainen profile image
Mikko Rantalainen

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?

Collapse
 
harounhajem profile image
Haroun Hajem

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.

Collapse
 
realsergiy profile image
realSergiy

"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?

Collapse
 
disukharev profile image
Dima Sukharev • Edited

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

Collapse
 
joriswitteman profile image
Joris W

A clean message is a message that communicates only what it should. Which is, why was this changed. Not how.

Collapse
 
billernet profile image
Bill💡

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

Thread Thread
 
jamesthomson profile image
James Thomson

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.

Thread Thread
 
ahtavarasmus profile image
rasmus

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

Collapse
 
usamashehab profile image
Usama Shehab

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?

Collapse
 
andypiper profile image
Andy Piper • Edited

Definitely checking this out, thanks for sharing. I don't use Twitter any more though - feel free to find me in the Fediverse ;-)

Collapse
 
mtrantalainen profile image
Mikko Rantalainen

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.

Collapse
 
disukharev profile image
Dima Sukharev

you can turn on the config description=true and see the why

Collapse
 
joriswitteman profile image
Joris W

So the AI knows why you made the change? Impressive.

Thread Thread
 
disukharev profile image
Dima Sukharev

you can try with:

npm i -g opencommit
oc config set OPENAI_API_KEY=<your_api_key>
oc config set description=true
Enter fullscreen mode Exit fullscreen mode

and then just run oc every time you want to commit smth

Thread Thread
 
joriswitteman profile image
Joris W

Doesn't that defeat the purpose of the whole thing?

Thread Thread
 
disukharev profile image
Dima Sukharev

i dont get you point, sorry :)

Thread Thread
 
jorisw profile image
Joris W • Edited

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?

Collapse
 
joriswitteman profile image
Joris W

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.

Collapse
 
raselinfo profile image
Rasel Hossain • Edited

how to edit message? if i need to change some text of the commit message

Collapse
 
disukharev profile image
Dima Sukharev

try oc hook set and turn on a setting to open git commit message as a file to edit in your IDE

Collapse
 
monkeycs60 profile image
Clément

I'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

Thread Thread
 
disukharev profile image
Dima Sukharev

try sudo oc hook set

Thread Thread
 
monkeycs60 profile image
Clément

It does not work

Thread Thread
 
hellowwworld profile image
hellowwworld

If you using windows you have to run vscode as administrator to make it work

Collapse
 
serjobas profile image
Sergey Bunas

I'm a big open commit user, can really recommend this stuff.

Saved me a lot of time on writing commit messages

Collapse
 
disukharev profile image
Dima Sukharev

great to see you here ;)

Collapse
 
cicko profile image
Rudolf Cicko

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.

Collapse
 
disukharev profile image
Dima Sukharev

mention Linus here pls :)

Collapse
 
devendra0110 profile image
Devendra Gaud

I just used it and it's awesome except one thing that it's NOT FREE 🥲

Collapse
 
disukharev profile image
Dima Sukharev

ChatGPT model is really cheap bro — it's like $0.15 for me each day

Collapse
 
abdurrkhalid333 profile image
Abdur Rehman Khalid

I have added this post and I am very excited to looking forward to using this as well.

Collapse
 
watzon profile image
Chris Watson

Absolute chefs kiss of a project. Thank you good sir.

Collapse
 
_eduard26 profile image
Eduard Constantin

oh boy, I could really use this to save some time

Collapse
 
deathlybower959 profile image
DeathlyBower959 • Edited

Isnt this bad to use? It defeats the purpose of a commit message, no? From my understanding, a commit message should be a description of WHY the changes happened, not WHAT happened.

Which would you rather read?

"Fix: Database overflow error"
"Add if statement to make sure index does not exceed database length"

I would much prefer to read the more concise, first message, as it explains the purpose of the code changed, and then the diff checker will show me exactly what is changed.

I'm not attacking this project, it looks quite cool, but saying "what" changed seems incorrect imo. Just learn how to write proper commit messages, it's not difficult to learn.

Edit: I see that you posted the same article 3 times with different names, so I know none of them are trustworthy and are just spam lol.

Collapse
 
hellowwworld profile image
hellowwworld

Use git-flow, get a life 😁 there's better things to do than write commit messages by yourself

Collapse
 
christianfreitag profile image
Christian Lima Freitag

Awesome! This is really helpful. I usually take few time thinking in the best description for commiting something and end up writing something like “second commit” haha. Amazing!

Collapse
 
speroamey profile image
Spero AMEY

Really cool, i appreciate it.

Collapse
 
disukharev profile image
Dima Sukharev

hahah, whats wrong with merge squash?

Collapse
 
joriswitteman profile image
Joris W

There's pros and cons.

A merge squash keeps the main branch's history shorter, and consolidates a PR's intent as a single message.

Not squashing means you can still see the exact reason behind each change in code. This can have its benefits. If people write decent commit messages.

It's a trade-off.

Collapse
 
smonff profile image
🌌 Sébastien Feugère ☔ • Edited

If we don’t know why we work on some bug fix or feature, and need GPT to write our commit messages, I don’t think that an AI will be helpful. Writing a commit message is a full part of communicating with other and make important reflexion progress. If we delegate that, I am almost sure we miss something.

Collapse
 
explorer14 profile image
Aman Agrawal

When you think of a commit message — you switch context from writing code. When you switch context — you waste time. Wasting time is lame

Thinking about what you are doing is not a waste of time its a part of our job as engineers! 🙂

Collapse
 
stanleysathler profile image
Stanley Sathler • Edited

Impressive how many people put so much effort to invalidate your creation.

"Commits should describe WHY, not WHAT."

Okay. Push a bunch of commits generated by the extension. Before you merge your PR, just squash it and name it whatever you prefer. Done. You got your WHY, but spent no time writing a bunch of other mini commits that probably no one cares after your PR is merged.

Nice work Dima! Not every innovation fits everyone unfortunately.

Collapse
 
artzeeker profile image
Artzeeker

Very very good, but sometime I want only one commit title but this generates multiple title in a staged changes i.e.

🎨 style(TabSearchJobs.tsx): improve readability by adding line breaks and aligning code
✨ feat(TabSearchJobs.tsx): add new category 'Jobs for Fresh Graduates' to the search filter

Collapse
 
pauldmurphy profile image
Paul Murphy • Edited

You could try something like this...

Company policy requires commit messages explain the "why" of the check-in and not the "what". Can you ask me questions regarding why I made the changes in this commit and then write a professional, technically accurate, succinct commit message for me?

Collapse
 
dbolser profile image
Dan Bolser

Hello. Love the religious wars, very educational and very respectful.

Please can you create a bot that 'unpick's (pun intended) my spaghetti diff commits into nice atomic commits following git flow conventions, running tests and squashing bug fixes?

kthxbi

Collapse
 
lukeocodes profile image
@lukeocodes 🕹👨‍💻

This is a great idea. I'd love to see you edit the prompts to have GPT follow conventional commits in it's output.

Collapse
 
chriisduran profile image
Christopher Duran

i don´t know Rick..

I prefer write by myself the commits.

Collapse
 
guydahn profile image
GuyDahn

Commits are the one thing i do right, why take it away from me? :<

Collapse
 
pterpmnta profile image
Pedro Pimienta M.

Thanks for the information.

Collapse
 
holiq profile image
Holiq Ibrahim

How about this? Who is better?
aicommits

Collapse
 
andreisuslov profile image
Andrei Suslov

Their messages are in past tense lol

Collapse
 
andreisuslov profile image
Andrei Suslov • Edited

Can I force the commit and push immediately after running "oc" without checking the message?

Collapse
 
dilenio profile image
Dilenio Enderle

I appreciate it!

Collapse
 
gamoreli profile image
Gabriel Moreli

Getting this error while trying to generate the commit message

connect ECONNREFUSED ::1:80

Anyone having the same issue?