DEV Community

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

Read full post

alexvoda • Mar 28 '23

This is very very BAD!!!!

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

Robert Kogan • Mar 28 '23

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.

alexvoda • Mar 29 '23 • 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.

Rolf Streefkerk • Mar 30 '23 • 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.

Alex Pushkarev • Mar 31 '23

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

Rolf Streefkerk • Apr 3 '23

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.

Andy Piper • Mar 27 '23 • Edited

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

Joris W • Mar 29 '23

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.

Mikko Rantalainen • Mar 28 '23

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.

Dima Sukharev • Mar 29 '23

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

Joris W • Mar 29 '23

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

Dima Sukharev • Mar 29 '23

you can try with:

npm i -g opencommit
oc config set OPENAI_API_KEY=<your_api_key>
oc config set description=true

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

Joris W • Mar 29 '23

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

Dima Sukharev • Mar 30 '23

i dont get you point, sorry :)

Rasel Hossain • Mar 27 '23 • Edited

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

Dima Sukharev • Mar 28 '23

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

Clément • Mar 28 '23

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

Dima Sukharev • Mar 29 '23

try sudo oc hook set

Clément • Mar 29 '23

It does not work

hellowwworld • Mar 31 '23

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

Sergey Bunas • Mar 27 '23

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

Saved me a lot of time on writing commit messages

Dima Sukharev • Mar 27 '23

great to see you here ;)

Rudolf Cicko • Mar 31 '23

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.

Abdur Rehman Khalid • Mar 29 '23

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

Dima Sukharev • Mar 27 '23

mention Linus here pls :)

Chris Watson • Mar 28 '23

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

Eduard Constantin • Mar 27 '23

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

Devendra Gaud • Mar 28 '23

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

Dima Sukharev • Mar 28 '23

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

Dima Sukharev • Mar 28 '23

hahah, whats wrong with merge squash?

Joris W • Mar 29 '23

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.

Christian Lima Freitag • Mar 28 '23

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!

Spero AMEY • Mar 29 '23

Really cool, i appreciate it.

DeathlyBower959 • Mar 30 '23 • 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.

hellowwworld • Mar 31 '23

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

🌌 Sébastien Feugère ☔ • May 5 '23 • 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.

Aman Agrawal • Apr 1 '23

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! 🙂

Stanley Sathler • Mar 31 '23 • 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.

Paul Murphy • May 15 '23 • 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?

Artzeeker • Mar 29 '23

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

Dan Bolser • May 21 '23

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