“It never reimplements git — it shells out to the system git CLI and rebuilds commits with git commit-tree, reusing each commit's original tree so file contents are provably never changed.”
Glad the LLM noted this - I was worried this would reimplement git
One of the most annoying quirks of LLMs for me is the insistence on, after being corrected, loudly noting what wasn't done. After getting it to change something stupid in code, it will leave a comment in the code boasting about how it doesn't do the stupid thing, which to future readers reads like an 'asbestos free!' label on a cereal box.
Lets assume one of two worlds - one where AI is constantly improving and one where the tooling is a dead end. In the first world the AI generated comments are no better than the commentary that would be generated in the next six months - in the second world the AI generated comments will obscure the human written comments.
In what world are AI generated comments actually value adds?
One of the reasons this is there is the "psychology" of the LLM performs better with these kinds of affirmations. If you've made a mistake once you're likely to make it again, so leave a note.
This indeed pollutes the code with a bunch of nonsense. One of the things I have it maintain instead is a "findings" document with lessons learned and such.
For what it's worth, I've used Claude to write a lot of smaller utility tools that I wouldn't normally have the time to sit down and implement, but which also solve straightforward problems.
One small example is an extension for the `gh` cli where I give it a PR number and multiple branches and it cherry-picks that PR to those branches, or lets me know if some of the branches don't work. For managing multiple release branches it's very handy, but not so handy that I would have spent a lot of time and energy doing a good job of it.
This seems like a similar sort of thing - a user friendly way to do something that most people don't need, and most people who need it probably don't need it very badly.
I haven't used claude to replace my actual skills - researching, solving problems, etc. - but I do use it to replace all the stuff which is essentially 'spend a few hours reading API docs and writing boilerplate code'.
That is in fact the difficult part. You have to explain it all coherently while adjusting to the reader's frame. No one does that for no good reason. It is hellish work.
Effective and clear communication is really important and often really hard for engineers. It is said that one goal of stackoverflow was to help programmers learn how to write through practice, as it’s both very hard and very critical to their effectiveness:
I mean, given that the English you wrote above didn't make it clear that was the only part you were complaining about, it's worth it to consider that maybe precision is hard in natural language regardless of how it's written
i definitely used to write bash functions for this sort of thing tho. no GUI, but it was useful to do stuff like obscure my working hours (make it look like i did personal stuff after-hours. make it seem like stuff took all day instead of an hour..like adding sawdust to meat).
like you said, niche and probably unnecessary. and if i were to have published them (even in a gist!) i would have written the docs myself instead of forcing people to read LLM-speak. That's just lazy.
Ha ha fair. But yeah shelling out to git and reusing the original tree object was deliberate means file contents can't change even if I screw up elsewhere.
2. Sometimes I split a Git repo into two, and I want to preserve the commit history (authors and dates) on the files that end up in the new repo - effectively replay the history of just one folder from the original to help create the new one.
3. I occasionally mess up cleaning up and merging a PR from an open source contributor such that the work is incorrectly credited to me. I'll fix the commit so that it credits the right person.
Yes, for instance it could be useful if someone’s been accidentally committing with a bogus email address. Or if you’re cleaning up some sort of mess and would like to recreate an accurate history.
Obviously as with any “force push” situation, the usual caveats apply if this is on a branch others have checked out, but if the mess is big enough, it is sometimes worth it to send everyone a script to reset or just to have people delete and re-check-out.
The few times I've wanted to completely rearrange a repo, It's been enough just make a backup branch and then dump the log from there and pull what I want.
I have script somewhere I think it's called git-cherry-replace, which soft resets a commit id and copies the commit message and optionally populates GIT_COMMITTER_DATE and whatnot.
What I described is probably simple enough that an LLM can implement it.
But unless you're trying to retroactively reconstruct something to preserve the exact meaning, you should consider whether a rebase even makes sense.
- An agent messed with my git config for some reason so I had to go back and fix the commit authorship
- I created a PR mostly based on work that someone else did, so I reauthored most of the commits to be in their name
Yes. Absolutely! Many times I had a wrong configured terminal and messed up the author. Often I work in different projects, privately and in my work, and I use different authors for both
Please put up this or another screenshot as the first thing you see in the README - please!
I'm reluctant to clone a repository and spend time on it just to find out the project looks crap and I don't want to use it. A screenshot saves other people's time :)
Two recent threads where I sing some praises of git rebase -i, specifically linking it to a spreadsheet. Awesome to see this pop up, feels serendipitous!
its vibecoded. just point another vibe based harness at it and youll have it in an hour or two. this thing is as trivial as you can get get, scope wise
I built a small Tauri app that just shows your commits in a table and lets you edit message/author/date directly, plus find & replace with regex if you need to fix a bunch at once. It backs up the branch before it rewrites anything doesn't touch file contents, just metadata.
“It never reimplements git — it shells out to the system git CLI and rebuilds commits with git commit-tree, reusing each commit's original tree so file contents are provably never changed.”
Glad the LLM noted this - I was worried this would reimplement git
One of the most annoying quirks of LLMs for me is the insistence on, after being corrected, loudly noting what wasn't done. After getting it to change something stupid in code, it will leave a comment in the code boasting about how it doesn't do the stupid thing, which to future readers reads like an 'asbestos free!' label on a cereal box.
I’ve left so many PR reviews in the last few months that are essentially “this looks good but delete 80% of the comments.”
Lets assume one of two worlds - one where AI is constantly improving and one where the tooling is a dead end. In the first world the AI generated comments are no better than the commentary that would be generated in the next six months - in the second world the AI generated comments will obscure the human written comments.
In what world are AI generated comments actually value adds?
this. like I feel that even telling sonnet 5 to explicitly not add comments it still produces them even on suppa simple logic
One of the reasons this is there is the "psychology" of the LLM performs better with these kinds of affirmations. If you've made a mistake once you're likely to make it again, so leave a note.
This indeed pollutes the code with a bunch of nonsense. One of the things I have it maintain instead is a "findings" document with lessons learned and such.
why can't anyone just do things themselves anymore? it's all LLM crap
For what it's worth, I've used Claude to write a lot of smaller utility tools that I wouldn't normally have the time to sit down and implement, but which also solve straightforward problems.
One small example is an extension for the `gh` cli where I give it a PR number and multiple branches and it cherry-picks that PR to those branches, or lets me know if some of the branches don't work. For managing multiple release branches it's very handy, but not so handy that I would have spent a lot of time and energy doing a good job of it.
This seems like a similar sort of thing - a user friendly way to do something that most people don't need, and most people who need it probably don't need it very badly.
I haven't used claude to replace my actual skills - researching, solving problems, etc. - but I do use it to replace all the stuff which is essentially 'spend a few hours reading API docs and writing boilerplate code'.
but if you were sharing those utilities - even in a github gist! - why not write the English parts for human consumption yourself?
That is in fact the difficult part. You have to explain it all coherently while adjusting to the reader's frame. No one does that for no good reason. It is hellish work.
git has a notoriously overcomplicated interface, so this is a scenario that I can honestly understand why someone wouldn't want to do it by hand
but what about the writing English to describe it part? does English also have a notoriously overcomplicated interface lol
Well, yeah, it does.
Effective and clear communication is really important and often really hard for engineers. It is said that one goal of stackoverflow was to help programmers learn how to write through practice, as it’s both very hard and very critical to their effectiveness:
https://blog.codinghorror.com/how-to-write-without-writing/
But programmers are also lazy*, so why put in the effort to improve when you can just get llms to do the work for you?
* not necessarily in a bad way
I mean, given that the English you wrote above didn't make it clear that was the only part you were complaining about, it's worth it to consider that maybe precision is hard in natural language regardless of how it's written
it is pretty clear in context given what i was responding to
They can, just in today's world, they just are not deemed impressive enough by the voting public to make it to the front page.
that's troubling..
Because I have better things to do with my time.
I have better things to do than read LLM prose copy-pasted verbatim too.
And yet here we are. I have to read LLM design docs that turn into LLM PRs with LLM PR descriptions and comments and docs.
A tool like this never sees the light of day without an LLM. Git is complicated and use case for this is rather niche.
i definitely used to write bash functions for this sort of thing tho. no GUI, but it was useful to do stuff like obscure my working hours (make it look like i did personal stuff after-hours. make it seem like stuff took all day instead of an hour..like adding sawdust to meat).
like you said, niche and probably unnecessary. and if i were to have published them (even in a gist!) i would have written the docs myself instead of forcing people to read LLM-speak. That's just lazy.
Yep, tell Claude to spit out a shell script. Use Python if bash is not enough.
It wasn't hard to just..figure it out though. One sitting tops.
Claude is learned (taught? lol) helplessness, at scale. I'm pretty sure it's their real moat.
If you dont use that regularly, why keep the app?
Ha ha fair. But yeah shelling out to git and reusing the original tree object was deliberate means file contents can't change even if I screw up elsewhere.
Why would you think such a project would reimplement git?
I believe that was sarcasm.
I appreciate that it uses git-notes and that is makes backup branches in it's own namespace. I wish it were a bit lighter though.
Haven't seen mentioned, but you might want to check out https://github.com/mystor/git-revise
This is cool, but has anyone ever needed to rewrite commit authors or dates?
I've needed to do this for a bunch of reasons.
1. Sometimes I do a scraping project where I want the commit dates to match when the data actually changed, reconstructed from sources like the Internet Archive or the dates on https://platform.claude.com/docs/en/release-notes/system-pro... - for example here: https://github.com/simonw/research/commits/main/extract-syst... - or this project that attempted to reconstruct the history of Tim Berners-Lee's original browser: https://github.com/simonw/1991-WWW-NeXT-Implementation/commi...
2. Sometimes I split a Git repo into two, and I want to preserve the commit history (authors and dates) on the files that end up in the new repo - effectively replay the history of just one folder from the original to help create the new one.
3. I occasionally mess up cleaning up and merging a PR from an open source contributor such that the work is incorrectly credited to me. I'll fix the commit so that it credits the right person.
git-filter-repo is amazing for the second case. I've used it to split repos and rename folders multiple times.
Yeah, I wrote a TIL about that a few years ago: https://til.simonwillison.net/git/rewrite-repo-specific-file...
Yes, for instance it could be useful if someone’s been accidentally committing with a bogus email address. Or if you’re cleaning up some sort of mess and would like to recreate an accurate history.
Obviously as with any “force push” situation, the usual caveats apply if this is on a branch others have checked out, but if the mess is big enough, it is sometimes worth it to send everyone a script to reset or just to have people delete and re-check-out.
If someone's been committing with a bogus email address and they're still working on the project, shouldn't they clean up their own commits?
Yeah, using this tool for example?
Usually its me who has been committing with a bogus email address, because I don't like having my real user/email set in my $HOME/.gitconfig
The few times I've wanted to completely rearrange a repo, It's been enough just make a backup branch and then dump the log from there and pull what I want.
I have script somewhere I think it's called git-cherry-replace, which soft resets a commit id and copies the commit message and optionally populates GIT_COMMITTER_DATE and whatnot.
What I described is probably simple enough that an LLM can implement it.
But unless you're trying to retroactively reconstruct something to preserve the exact meaning, you should consider whether a rebase even makes sense.
Times I have needed to do this:
I have never personally needed to touch dates.Yes. Absolutely! Many times I had a wrong configured terminal and messed up the author. Often I work in different projects, privately and in my work, and I use different authors for both
yes; when i wanted to make it look like i didn’t procrastinate for a week and implement the entire feature in one day
Hmmm, this seems to be making easy something you normally should not do.
So, exactly like a knife? Generally we don't want to cut people open, but when we need to do it, like during surgery, a sharp knife sure helps.
that's it
Agreed mostly. The intent is local cleanup before you push like fixing a wrong author email across a batch or dates from a machine with a bad clock
I would like to see something like this in magit. Other there is already?
No idea not an emacs person does magit handle bulk author/date edits or just reword? genuinely curious
This looks cool! Are there screenshots available?
https://imgur.com/a/V5EGCOw
Please put up this or another screenshot as the first thing you see in the README - please!
I'm reluctant to clone a repository and spend time on it just to find out the project looks crap and I don't want to use it. A screenshot saves other people's time :)
done
Unreadable in iPad Safari -- delayed popup darkens the screen and demands app install.
ah that's imgur. moved it to a github-hosted image should be fine now.
Thanks, but is that a photo of a screen instead of a screenshot and that’s why it looks cloudy/random splotches are brighter?
Regardless, it’s better than nothing, thank you.
I'd put that in the repo not here.
you're right, done
Two recent threads where I sing some praises of git rebase -i, specifically linking it to a spreadsheet. Awesome to see this pop up, feels serendipitous!
Git rebase -i is not that scary 119 points, 16 days ago, 151 comments https://news.ycombinator.com/item?id=49053385 https://cachebag.sh/journal/interactive-rebasing/
Staging patches with git add 34 points, 12 days ago, 52 comments https://news.ycombinator.com/item?id=49048570 https://cachebag.sh/journal/interactive-rebasing/
Really enjoying jj these days but the git rebase -i spreadsheet remains such a winner. Expanding it more, leaning in, ftw.
Extra points for the name.
Appreciate it! pick a commit, stab it
Slicing or cutting fat is imho better ;)
Would be great to have this, but as a TUI tabular editor.
its vibecoded. just point another vibe based harness at it and youll have it in an hour or two. this thing is as trivial as you can get get, scope wise
I built a small Tauri app that just shows your commits in a table and lets you edit message/author/date directly, plus find & replace with regex if you need to fix a bunch at once. It backs up the branch before it rewrites anything doesn't touch file contents, just metadata.