Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
YonathanTesfaye
146 points
93 comments
August 11, 2026
Related Discussions
Found 5 related stories in 40.5ms across 4,128 title embeddings via pgvector HNSW
- Committing to Git: Rebuilding ReadMe on Git gkoberger · 11 pts · July 21, 2026 · 55% similar
- The Git history command deserves more attention turbocon · 179 pts · July 14, 2026 · 55% similar
- Show HN: CodeAlmanac – Karpathy-style codebase wiki from your conversations divitsheth · 48 pts · July 21, 2026 · 53% similar
- Show HN: Structural code grep across public GitHub repositories mohebifar · 12 pts · August 22, 2026 · 52% similar
- Show HN: Graft – Claude Code hooks that cut grep tokens by 42% shrishdwi · 39 pts · August 14, 2026 · 50% similar
Discussion Highlights (15 comments)
YonathanTesfaye
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.
cautiouscat
This looks cool! Are there screenshots available?
sixtyj
Extra points for the name.
mellosouls
Hmmm, this seems to be making easy something you normally should not do.
iamcoder18
This is cool, but has anyone ever needed to rewrite commit authors or dates?
f1shy
I would like to see something like this in magit. Other there is already?
NichoPaolucci
“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
hootz
Would be great to have this, but as a TUI tabular editor.
jauntywundrkind
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.
unqueued
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
beart
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.
lrvick
Note: This will not work and cannot work on repos that use signed commits from multiple authors. 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
dhruv3006
that's a catchy name - good luck.
Defletter
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.
vivzkestrel
- make a drag and drop ui for git rebase - i should be able to change order of commits - i should be able to change what files went in a previous commit