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.
- 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
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.
Very rarely. But it can come up if you archive change history in git for things that aren't originally tracked in git.
Take laws for example. Legalize[1] is a project that documents all laws into a git structure where each distinct change is a commit with the proper timestamp of tha change. Sure, this specific project builds that entire git history once and it's unlikely a retroactive change required such edits. But do something like this for historical sources where information is still coming in, and you might need to change a date when new findings occur.
“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.
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
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!
It looks like the screenshot was an actual photo of someone's monitor. I'm left wondering why print screen wasn't utilized. And for some reason it really makes me not want to touch this project.
This is, funnily enough, something I've been periodically searching for for nearly a decade, and even renewed my search yesterday. For those wondering, my use case is a model Parliament (context: https://news.ycombinator.com/item?id=43474850) and deciding on using git to store the laws, with the commits representing the Acts of Parliament themselves. The problem is that we need to guarantee that every commit has the correct metadata: we do not care at all about the conservation of commit hashes. And if we've accidentally missed a law and need to interactively-rebase it into the git history, it should NOT reset all the subsequent commit dates to the current timestamp. Basically, we're wanting to use git as a historical archive. I'm delighted to have found this.
30 comments
[ 0.29 ms ] story [ 11.0 ms ] threadI 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.
Take laws for example. Legalize[1] is a project that documents all laws into a git structure where each distinct change is a commit with the proper timestamp of tha change. Sure, this specific project builds that entire git history once and it's unlikely a retroactive change required such edits. But do something like this for historical sources where information is still coming in, and you might need to change a date when new findings occur.
[1] https://github.com/legalize-dev/legalize
Yes. Plenty of times.
Glad the LLM noted this - I was worried this would reimplement git
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.
Haven't seen mentioned, but you might want to check out https://github.com/mystor/git-revise
Signed git history is immutable, and unsigned git history is a supply chain attack vector.
That said I could see this being useful for single-author WIP branches doing cleanup before a PR
- i should be able to change order of commits
- i should be able to change what files went in a previous commit