Have Gemini stage and write commit messages for you(github.com)
github.com
Have Gemini stage and write commit messages for you
https://github.com/suwi-lanji/auto-commit
55 comments
Yep. You should stop and answer “why does this commit exist?” since that is the question you will be asking yourself when you discover it with `git blame` or `git bisect`. It amazes me how many devs are just willing to slap a -m on `git commit` and just say “fix bug” or “pr feedback”.
Thank you for the response,
My target is people that are bad at writing commits, barely or don't even write commits. Also from what you arguing I've worked on alot of projects including opensource and the majority just provide a quick summary so this would be of great use.
Here are some commits the bot wrote
feat: Enhance Auto-Commit Bot with new features and improvements - Reworked the description to provide a more detailed overview of the tool's capabilities. - Added badges for license and Python version. - Updated the installation instructions to include environment variable setup for the Google Gemini API key. - Implemented logging for all actions to facilitate debugging and provide a comprehensive record of events. - Included a usage example to demonstrate the workflow of the tool. - Improved the commit message generation using the Google Gemini API for increased accuracy and context.
And
feat: integrate Gemini API for commit message generation This commit introduces integration with the Gemini API to enhance the automated commit message generation process.
The following changes were made:
- Added a `CommitMessageGenerator` class to generate commit messages using the Gemini API. - Modified the `ChangeDetector` to handle the generation and staging of commit messages. - Updated the CLI to accept an API key for Gemini API access. - Added error handling for missing API keys. - Implemented tests for the `CommitMessageGenerator`.
feat: Enhance Auto-Commit Bot with new features and improvements - Reworked the description to provide a more detailed overview of the tool's capabilities. - Added badges for license and Python version. - Updated the installation instructions to include environment variable setup for the Google Gemini API key. - Implemented logging for all actions to facilitate debugging and provide a comprehensive record of events. - Included a usage example to demonstrate the workflow of the tool. - Improved the commit message generation using the Google Gemini API for increased accuracy and context.
And
feat: integrate Gemini API for commit message generation This commit introduces integration with the Gemini API to enhance the automated commit message generation process.
The following changes were made:
- Added a `CommitMessageGenerator` class to generate commit messages using the Gemini API. - Modified the `ChangeDetector` to handle the generation and staging of commit messages. - Updated the CLI to accept an API key for Gemini API access. - Added error handling for missing API keys. - Implemented tests for the `CommitMessageGenerator`.
Yes, when spelunking why something has changed having good rationality would be a godsend... however let's face reality:
1. Majority of commit messages are low quality and would benefit significantly from a good summary of what was done.
2. Margin of commit messages is often too small for documenting the rationale - this job is better left for tickets.
1. Majority of commit messages are low quality and would benefit significantly from a good summary of what was done.
2. Margin of commit messages is often too small for documenting the rationale - this job is better left for tickets.
> 2. Margin of commit messages is often too small for documenting the rationale - this job is better left for tickets.
The commit message lives with the code. The number of times in my career that a company has migrated, changed, consolidated, or otherwise made all those links in commit messages obsolete, well I don't quite yet need two hands. But I see a lot of dead ends to context in code bases.
The commit message lives with the code. The number of times in my career that a company has migrated, changed, consolidated, or otherwise made all those links in commit messages obsolete, well I don't quite yet need two hands. But I see a lot of dead ends to context in code bases.
Nothing stopping someone from deciding to migrate VCSs (or even just repos) and all of a sudden end up in the place that 15 years of codebase history is squashed down to a single new starting commit. :(
Don’t forget that most modern version control systems are distributed. The same can not be said for ticketing systems.
> Majority of commit messages are low quality and would benefit significantly from a good summary of what was done.
Why? At that point doesn't the diff speak for itself?
Why? At that point doesn't the diff speak for itself?
Not to mention, the best commit messages are about the code that isn’t there.
As you say, we know what’s there. I need the author to tell me why it’s there, and perhaps what other alternatives were abandoned because they didn’t work.
You know, so I don’t waste a day finding out for myself why you didn’t just do ${obvious}.
As you say, we know what’s there. I need the author to tell me why it’s there, and perhaps what other alternatives were abandoned because they didn’t work.
You know, so I don’t waste a day finding out for myself why you didn’t just do ${obvious}.
If the content of the commit is too small to be meaningful, the commit is too small. Either wait until you’ve done more before committing, or rebase -i before pushing your branch and merge up any piecemeal commits into better sized ones that communicate a story.
Keeping that metadata in tickets means that it can’t be read within ‘git blame’. It’s also all too easy for it to be lost entirely when changing ticketing systems, transferring codebases between teams or companies, etc.
Keeping that metadata in tickets means that it can’t be read within ‘git blame’. It’s also all too easy for it to be lost entirely when changing ticketing systems, transferring codebases between teams or companies, etc.
Well, that is exactly what the code does right now: https://github.com/suwi-lanji/auto-commit/blob/40c1fc34adce5....
I would probably have it look at the files and try to generate a nice summary of “why”, but for those minor things where you add a parameter or fix whitespace I think this is OKish.
I would probably have it look at the files and try to generate a nice summary of “why”, but for those minor things where you add a parameter or fix whitespace I think this is OKish.
[deleted]
True, but you can infer the why from what changed for a lot of cases
e.g. - Add types for X, Y Z
if the PR goal is to make types more strict, that message is clear.
I feel like the quality will be worse than if the engineer really put some thought into it, but the problem is, commits are annoying to write.
A lot of people do “wip” or do a worse than average job.
Having a summary of what changed is still better than that.
Edit: if you feed more context about what you’re trying to develop it will probably be able to infer.
e.g. - Add types for X, Y Z
if the PR goal is to make types more strict, that message is clear.
I feel like the quality will be worse than if the engineer really put some thought into it, but the problem is, commits are annoying to write.
A lot of people do “wip” or do a worse than average job.
Having a summary of what changed is still better than that.
Edit: if you feed more context about what you’re trying to develop it will probably be able to infer.
I’d rather have «wip» commit messages, and thus forced to open the diff, than worrying of the message being hallucinated.
I’m totally cool with people using this as an initial draft and then manually tweaking it though.
I’m totally cool with people using this as an initial draft and then manually tweaking it though.
Commits are annoying to write is in the same space as "variable names are annoying to write".
Communicating intent should be trivial or, if it's not, put effort into it because communication with that future dev may be essential .
Now, maybe some bullet points may suffice and quickly be reshaped by AI to make it more succinct and clear but you still should make the effort. The more you do it, the more it becomes an easy part.
The problem is when you copy and paste the same info in slightly different ways in many places and I can appreciate some form of suggestion around "you missed explaining why you want to change this part".
There's a space for AIb but it isn't "so that I don't need to think".
Communicating intent should be trivial or, if it's not, put effort into it because communication with that future dev may be essential .
Now, maybe some bullet points may suffice and quickly be reshaped by AI to make it more succinct and clear but you still should make the effort. The more you do it, the more it becomes an easy part.
The problem is when you copy and paste the same info in slightly different ways in many places and I can appreciate some form of suggestion around "you missed explaining why you want to change this part".
There's a space for AIb but it isn't "so that I don't need to think".
I've never worked that way.
In my mind, commit messages should be a quick summary of what. The basic motivation should be clearly labeled as a feature, bugfix, etc., but that's all. Commit messages are for quick browsing and a summary of what changed, not extensive justification.
The why is too important to be put in a commit message. The product why belongs in a linked issue that describes the bug or use case in full detail. Meanwhile, the technical why's (why this particular solution as opposed to alternatives) belong in the code itself as comments.
In my mind, commit messages should be a quick summary of what. The basic motivation should be clearly labeled as a feature, bugfix, etc., but that's all. Commit messages are for quick browsing and a summary of what changed, not extensive justification.
The why is too important to be put in a commit message. The product why belongs in a linked issue that describes the bug or use case in full detail. Meanwhile, the technical why's (why this particular solution as opposed to alternatives) belong in the code itself as comments.
The first line (or atleast, the first 80 characters) should be a quick summary - so you can quickly browse via git blame.
But the actual commit message should consist of History/Motivation/Context - so that someone who's going through the blame can understand why a certain change was made, and what the context was.
Linus had a good template for this, which makes a lot of sense: https://gist.github.com/finalfantasia/bd0070673ca27e5f7473
But the actual commit message should consist of History/Motivation/Context - so that someone who's going through the blame can understand why a certain change was made, and what the context was.
Linus had a good template for this, which makes a lot of sense: https://gist.github.com/finalfantasia/bd0070673ca27e5f7473
If I want history, motivation and context to actually be read at some point I put it in tests, code comments and README/docs.
If I want my history, motivation and context to be ephemeral I put it in a commit message.
It still perplexes me why people obsess over commit messages while the places where people are actually looking when they have these questions are neglected.
If I want my history, motivation and context to be ephemeral I put it in a commit message.
It still perplexes me why people obsess over commit messages while the places where people are actually looking when they have these questions are neglected.
I don't particularly want a commit log at the top of every function, TBH. If I'm looking for the history and context of a change, I want to look at the commit log. If I want a description of the current version, I look in the docs (and yeah, sometime I can only piece together why something is the way it is now by looking through how it's changed. But documenting each change has a much better chance of addressing questions like "why did it work and now it doesn't" then trying to get the docs perfect will.)
>I don't particularly want a commit log at the top of every function
If thats what you got from my comment then you misinterpreted it.
Nobody wants docs to look like commit messages. They want them to be relevant to the context.
If thats what you got from my comment then you misinterpreted it.
Nobody wants docs to look like commit messages. They want them to be relevant to the context.
{Tests, Code Comments, Documentation} are 3 distinct places to trawl through when quickly going through git blame.
The commit message is one place - and gives the author an opportunity to speak directly with a future developer over the place-in-time-context that this change was made.
The commit message is one place - and gives the author an opportunity to speak directly with a future developer over the place-in-time-context that this change was made.
Git blame is something you use to ask "what the fuck"? Hence why it's got the tongue in cheek moniker "git blame".
If devs are constantly asking "what the fuck?" all over the code base then that's usually coz tests, code comments, docs and code quality were all badly neglected.
Better commit messages are a band aid over that gaping wound.
If devs are constantly asking "what the fuck?" all over the code base then that's usually coz tests, code comments, docs and code quality were all badly neglected.
Better commit messages are a band aid over that gaping wound.
You're focusing a bit much on the Developers bit.
It's not just Developers who are working through the code-base.
As a lame example - Incident Response/SRE will also be trying to get their heads around changes being made - especially if they're responding to an outage, and trying to figure out what change broke production - and why it was made.
Not everyone will know every bit of the project as intimately as the Dev team - and having a good commit message will help any unfamiliar response team mitigate, or escalate accordingly.
As a lame example - Incident Response/SRE will also be trying to get their heads around changes being made - especially if they're responding to an outage, and trying to figure out what change broke production - and why it was made.
Not everyone will know every bit of the project as intimately as the Dev team - and having a good commit message will help any unfamiliar response team mitigate, or escalate accordingly.
You think incident response would also prefer to go digging around using git blame than just reading your docs?
If you put some effort into your runbooks, not your commit messages, thats where they'll really appreciate good, detailed writing.
If you put some effort into your runbooks, not your commit messages, thats where they'll really appreciate good, detailed writing.
Issues are not part of the source code repository. The issue tracker may not be there anymore at some point in the future, and it also may not be accessible when you work offline.
I agree about the technical justifications belonging in the source code itself as comments.
I agree about the technical justifications belonging in the source code itself as comments.
Also when the issue is a bug the information you'll find in the tracker is usually about the symptoms and says nothing about the fix.
> The product why belongs in a linked issue that describes the bug or use case in full detail.
That's nice until you switch git hosts or project management systems and the context is lost. Commits live forever, use them.
At least a small summary of "why" would've been so helpful many times in the legacy codebase I maintain instead of "fix tests", "format", "FOO-123"
That's nice until you switch git hosts or project management systems and the context is lost. Commits live forever, use them.
At least a small summary of "why" would've been so helpful many times in the legacy codebase I maintain instead of "fix tests", "format", "FOO-123"
This sort of thing probably doesn't work particularly well with file auto-saving, which is almost necessary for some language servers to reprocess files to reflect "real-time" in VSCode. Aren't you also just committing half-baked work and totally menial changes?
I tried this with a random commit from one of my projects: https://github.com/masto/LED-Marquee/commit/775d48fc0dd969de.... You can read my human-crafted message there. By comparison, what follows is the one that Gemini came up with which is A: useless, and B: wrong. I don't want to be mean, but I would put this up there as almost the perfect example of what generative AI should never be used for. It cannot read your mind, and the commit description is where you say what the intention of the change is, not summarize what it contains.
Fix: Remove platformio.ini from .gitignore and rename platformio.ini.dist
This commit removes platformio.ini from the .gitignore file and renames
platformio.ini.dist to platformio.ini. This allows the project's PlatformIO
configuration to be tracked by Git and ensures consistent build settings across
development environments. It also adds comments explaining how to configure OTA
updates and override settings with a separate marquee.ini file.Please don't jump on me:
Am I the only person in this world who is an accomplished engineer and thinks commit messages are worthless? That if I want to roll back or dissect, I do it at the PR and not individual commit level?
The need for very accurate comment messages occurs so rarely in my workflow that the value of crafting them correctly is not there.
I ask honestly: Am I missing something here? Why? Is it something peculiar to my workflow I'm missing?
Am I the only person in this world who is an accomplished engineer and thinks commit messages are worthless? That if I want to roll back or dissect, I do it at the PR and not individual commit level?
The need for very accurate comment messages occurs so rarely in my workflow that the value of crafting them correctly is not there.
I ask honestly: Am I missing something here? Why? Is it something peculiar to my workflow I'm missing?
In my experience, most of the value in commit messages isn't in rolling back and such, but in trying to understand history. At day job, I work on a product where some of the code is around two decades old, so you bet there's no one around who you could ask about it. Many of the problems that were solved at the time are solved for free out of the box with modern tooling, but you won't know if that's the case unless you know what problem a commit was fixing to begin with. You can read the diff, yes, but it won't tell you the why and that's what commit messages are for.
I think a lot of people here maybe haven't used a PR + squash merge flow? Because I agree with you, when I'm doing operations on git history I just see the PR title from the squash merge. Squash merge lets the PR be the atomic unit, so commit messages don't matter as much.
But if I read these comments as "I wouldn't let an AI write my PR description", I strongly agree.
But if I read these comments as "I wouldn't let an AI write my PR description", I strongly agree.
It depends on your workflow, ofc.
If you run the kind of shop where your master branch is all merge commits, commit messages are useful.
If you run the kind of shop where your master branch is all merge commits, commit messages are useful.
Working in production and fixing bugs I find them totally invaluable.
For commit messages, the world seems full of bad commit messages, and commit hygiene. Does this do anything to help improve that? What I really want is a bot that groups my changes into logical commits. I.e. I tell what kind of change I want committed, and it stages only those patches.
I noticed today that one of the big hardware stores in Switzerland has started using LLMs to generate descriptions. As expected, it's just drivel:
> Do you need a new sealing ring for your washbasin siphon? No problem. The Geberit plug-in seal is exactly what you need. With a diameter of 32/46 mm, it fits perfectly and ensures that everything is tight. It has a height of 5.5 cm and a length of 2.3 cm, making it easy to handle and quick to install. It's simply worth its weight in gold when everything fits at the first attempt and you don't have to worry about whether the quality is right. So, whenever your washbasin siphon needs a refresh, the Geberit plug-in seal with its 3.2 cm is your first choice. Simply insert and you're done.
https://www.jumbo.ch/de/bad-sanitaer/installationsmaterial/d...
I noticed today that one of the big hardware stores in Switzerland has started using LLMs to generate descriptions. As expected, it's just drivel:
> Do you need a new sealing ring for your washbasin siphon? No problem. The Geberit plug-in seal is exactly what you need. With a diameter of 32/46 mm, it fits perfectly and ensures that everything is tight. It has a height of 5.5 cm and a length of 2.3 cm, making it easy to handle and quick to install. It's simply worth its weight in gold when everything fits at the first attempt and you don't have to worry about whether the quality is right. So, whenever your washbasin siphon needs a refresh, the Geberit plug-in seal with its 3.2 cm is your first choice. Simply insert and you're done.
https://www.jumbo.ch/de/bad-sanitaer/installationsmaterial/d...
People who are "programmers by coincidence" and think that commit messages or unit tests are a chore and they just do it to satisfy orders from other devs are the first who think have the AI do it is a good idea.
There's a reason people feel TDD is hard if they don't want to think about properly modeling their problem. Reducing duplication and finding a good human computer interface with AI is great but if you just don't want to think at all, you'll just dump crap on the next guy and it's natural that you're "worried about being replaced by AI".
There's a reason people feel TDD is hard if they don't want to think about properly modeling their problem. Reducing duplication and finding a good human computer interface with AI is great but if you just don't want to think at all, you'll just dump crap on the next guy and it's natural that you're "worried about being replaced by AI".
You sound pretty elevated would like to see your work and how you approach development practices,
Secondly of you have actually worked on opensource projects and seen how people write commits you realize that the summaries are not so informative and you would have to go through the code to really know what was changed so having ai help you write messages is for the betterment of others to get a more detailed summary
Also this was an afternoon project I did before I had a meeting just for fun
Also this was an afternoon project I did before I had a meeting just for fun
You're misinterpreting my comments as "don't do things". This is HN, do things for the sake of doing them. It's fine.
My points are valid though and if you want to argue them on their merits instead of throwing misguided and ignorant insults you're welcome to do so.
My points are valid though and if you want to argue them on their merits instead of throwing misguided and ignorant insults you're welcome to do so.
I don't see any insults in my reply though apologies if it sounded offensive, my point is only to express the fact that ai would be a great tool for writing commits and though this project is no where close to being usable
[deleted]
No actually just write your own commit messages. Generally speaking, just write your own stuff.
This is a terrible idea. Do not do this.
The Auto-Commit Bot is a Python-based tool that automatically monitors a directory for changes, generates meaningful commit messages using the Google Gemini API, and commits the changes to a Git repository. It’s perfect for automating repetitive Git tasks and ensuring consistent commit messages.
These are not meaningful commit messages. A meaningful message says why something was done, not what files were changed. You can see what files were changed in every commit without writing it in the commit message.
I would argue most people don't write meaningful commits also this was done in 2-3 hours so don't expect it to be perfect
This doesn't let you include multiple files in a commit, right?
"feat: Enhance Auto-Commit Bot with new features and improvements"
It's definitely _a_ commit message. Not sure it beats "asdasd" or "do stuff" though.
It's definitely _a_ commit message. Not sure it beats "asdasd" or "do stuff" though.
def generate_commit_message(self, diff):
"""
Generate a commit message using the Gemini API.
"""
prompt = f"Generate a concise and meaningful Git commit message for the following changes:\n\n{diff}"
response = self.model.generate_content(prompt)
return response.text.strip()
OTOH, it's an open source base and one can PR to it.
Thanks for the suggestion it was a boring afternoon so I decided to do something with gemini api so it's not something that I put much effort it
We are automating commit messages now? Is it really that much of an effort to simply phrase what you just developed and type it out?
Cursor has this conveniently built in. I find it pretty handy, specially for wip commits
It doesn’t know the intent of the commit though, so if you change X because of Y, it will just tell that X changed, without explaining why.
Adding more context about what the ticket is about can probably solve that
It doesn’t know the intent of the commit though, so if you change X because of Y, it will just tell that X changed, without explaining why.
Adding more context about what the ticket is about can probably solve that
I haven't been able to find that in the app
Copilot already proposes commit messages for you, right?
Commit message is not just a quick summary of what, it's also a historical record of why. Can't generate the latter from the diff.