_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Show HN: Git Auto Commit (GAC) â LLM-powered Git commit command line tool
torqu3e wrote 1 hour 27 min ago:
Here's the 20 line bash version I whipped up a while back cuz yes lazy
about writing good commit messages.
Supports claude and gemini with model selection and goes into the
githook such that when you type `git commit` it invokes and generates
the message.
HTML [1]: https://gist.github.com/torqu3e/c08f4aa4e80fba66dce6c35d63dd08...
ClimaxGravely wrote 18 hours 41 min ago:
Maybe it's because these days I use perforce more than git but I tend
to find myself writing 80% of my commit message before I write any code
and touch it up a little at the end.
bangaladore wrote 18 hours 50 min ago:
> Automatic secret detection: Scans for API keys, passwords, and tokens
before committing
Surely this is done on-device right? Or is the prompt asking the LLM if
there are secrets in the changes.
Arguably I trust Github / Gitlab / etc more than OpenAI / Anthropic /
etc
merge-conflict wrote 18 hours 44 min ago:
The scanning is done on-device. I should've worded it better and said
that it scans before any API calls. Too late to edit the post,
unfortunately.
0x008 wrote 18 hours 58 min ago:
I like the lazycommit+lazygit combo.
HTML [1]: https://github.com/m7medVision/lazycommit
paulirish wrote 19 hours 21 min ago:
Chiming in with my alternative, like others' but uses simonw's `llm`:
git upstream-diff | llm --system-fragment cl-description.md
However, in practice, I notice the generated messages focus more on the
what than the why. So it's rare I use them verbatim.
glitch253 wrote 20 hours 15 min ago:
Hey all - disclaimer I'm one of Cell's friends and encouraged them to
release their utility on Pypi for others. It quickly became one of my
favorite tools that I use every day.
`git commit` is gone, `uvx gac` is in!
cypriss9 wrote 20 hours 40 min ago:
There's three types of people: those who already write excellent commit
messages explaining the why, those who write decent ones explaining the
what, and those who write garbage commit messages. Empirically, the
first set is small. This tool will help the middle type be more
efficient, and help the last type drastically.
Well done OP.
ah27182 wrote 20 hours 52 min ago:
I've been using LMStudio to run a local LLM (Qwen3-4B) to generate
commit messages using this command:
```
git diff --staged --diff-filter=ACMRTUXB | jq -Rs --arg prompt 'You are
an assistant that writes concise, conventional commit messages. Always
start with one of these verbs: feat, fix, chore, docs, style, refactor,
test, perf. Write a short!! message describing the following diff:'
'{model:"qwen/qwen3-4b-2507", input:($prompt + "\n\n" + .)}' | curl -s
http://localhost:1234/v1/responses -H "Content-Type: application/json"
-d @- | jq -r ".output[0].content[0].text"
```
rwdf wrote 21 hours 0 min ago:
"gac" is giving me PTSD flashbacks from having to deal with the "Global
Assembly Cache" aeons ago.
martinohansen wrote 21 hours 2 min ago:
I donât get these kind of tools. A commit should be the why of a
change, not a summary of what it is, anyone can either get that
themselves or just read the code if they desire. What you can not get
from the code is the _why_ which only you as the author can put.
Ferret7446 wrote 11 hours 8 min ago:
There are plenty of commits that don't need an explanation like
mechanical cleanups or refactoring. If your code is appropriately
documented then an LLM can often extract the explanation too.
martinohansen wrote 3 hours 25 min ago:
If there truly is no need for an explanation, the commit message is
very short and wonât require any substantial effort on the author
to write.
A fix often has a particular bug itâs addressed, the bug should
be explained in the commit. A refactor has a reason, that needs to
be explained as well.
Iâm not saying LLMs canât do this, but it needs the context and
itâs rarely in the diff of the commit you will find that.
derwiki wrote 20 hours 47 min ago:
I often start a change by having Cursor read the Slack thread (via
MCP) that is motivating the change. In the same Cursor thread, after
making the change, it has fairly good context on the _why_ and writes
a helpful commit message.
therein wrote 19 hours 29 min ago:
Very nice, the fewer neurons you use the better. In biology they
call it use it and lose it if my memory serves me correctly.
Neurons that fire together, fry together.
pbh101 wrote 16 hours 45 min ago:
While Iâm deeply skeptical of any attempt to define a commit
message from the diff, if the context and motivation is truly
captured in the Slack thread or other prior documents and
available for summarization, then how many neurons are you really
using on rewording what you already hashed out? Especially if
someone would otherwise perhaps skip a message or write a poor
one, this sounds like a great approach to get at least a first
pass to further modify.
nvartolomei wrote 20 hours 57 min ago:
I do often ask Claude Code or Gemini CLI to write commits. I agree
with you on why being important. Majority of these being bug fixes
accompanied tests where the why is easily inferred from the
change/newly added tests and their comments.
bigwheels wrote 21 hours 7 min ago:
aicommit2 works great: [1] Getting started is as easy as installing
claude/codex/gemini: npm install -g aicommit2
I'm excited to give gac a try and see how it stacks up! The steering
hints with gac might give it an edge.
HTML [1]: https://github.com/tak-bro/aicommit2
nicksergeant wrote 21 hours 25 min ago:
Neat project. If you're looking for something simpler just to use w/
Claude Code, a simple call to "claude -p" can work:
HTML [1]: https://github.com/nicksergeant/dotfiles/blob/master/zshrc#L33...
merge-conflict wrote 21 hours 21 min ago:
Thanks! Can definitely do that, but GAC is faster than calling claude
or another agent as they will take multiple api calls to look at git
status, git diffs, etc. vs a single api call with GAC. Plus, GAC
won't eat up your weekly limits! ;)
nicksergeant wrote 21 hours 17 min ago:
Oh I just pipe the diff into the Claude prompt, so it's only the
one call.
Steeeve wrote 21 hours 27 min ago:
Your scientists were so preoccupied with whether or not they could,
they didn't stop to think if they should.
dang wrote 19 hours 51 min ago:
Omit internet tropes.
HTML [1]: https://news.ycombinator.com/newsguidelines.html
adrianbooth17 wrote 21 hours 33 min ago:
Very neat little project, I look forward to trying this
avinash-iitb wrote 21 hours 45 min ago:
I like that youâve added secret detection and multi-provider support
â thatâs something most LLM commit tools miss.
Have you benchmarked latency differences between local models (like
Ollama) and OpenAI/Anthropic? Would be interesting to see a speed
comparison.
alwillis wrote 21 hours 56 min ago:
Hate writing commit messages.
Just installed gac; they nailed the UI/UX.
And so far, it works quite well.
merge-conflict wrote 21 hours 40 min ago:
Thank you! I used a combination of the questionary and click python
libraries for the ui/ux.
seba_dos1 wrote 22 hours 3 min ago:
This misses the point of what a good commit message is so much that it
could be a delightful satire.
jacobsenscott wrote 21 hours 12 min ago:
Yeah - if these are better than your current commit messages, just
don't write commit messages. Anyone can read the code.
acoliver wrote 20 hours 8 min ago:
side-eye "anyone can read the code" -- usually the first words of
someone who writes unreadable code.
perl
-e'$_=q/dk|jk`%fdk%w`da%qm`%fja`/;s/./chr(ord($&)^5)/seg;print'
acoliver wrote 22 hours 35 min ago:
Oh nice. Man I hate filling out all that stuff. And getting the LLM to
do it without freestyling and hallucinating is a pain. Kinda wish it
were an MCP so I can shove it in my CLI or maybe the hooks for git...
merge-conflict wrote 22 hours 22 min ago:
I'm considering making it optionally work as an MCP server!
DIR <- back to front page