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.
Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
81–90 of 111 posts
Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
#82Earlier quoted context omitted.
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?
Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
#83It 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.
I thought it was a semi-transparent window until I read this. The curvature makes that clear, wow!
Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
#84It 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.
exiftool -a -u -g1 ~/Downloads/screenshot.png
---- ExifTool ----
ExifTool Version Number : 13.55
---- System ----
File Name : screenshot.png
Directory : XXX
File Size : 1260 kB
File Modification Date/Time : 2026:08:11 16:24:37-04:00
File Access Date/Time : 2026:08:11 16:24:41-04:00
File Inode Change Date/Time : 2026:08:11 16:24:41-04:00
File Permissions : -rw-r--r--
---- File ----
File Type : PNG
File Type Extension : png
MIME Type : image/png
---- PNG ----
Image Width : 2351
Image Height : 1388
Bit Depth : 8
Color Type : RGB with Alpha
Compression : Deflate/Inflate
Filter : Adaptive
Interlace : Noninterlaced
Significant Bits : 8 8 8 8
Software : gnome-screenshot
Creation Time : Mon 10 Aug 2026 10:19:53 PM +03
---- Composite ----
Image Size : 2351x1388
Megapixels : 3.3Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
#85It 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.
Looking at the metadata it says it is a Gnome screenshot. What a pointless and incorrect non-sequitor. exiftool -a -u -g1 ~/Downloads/screenshot.png ---- ExifTool ---- ExifTool Version Number : 13.55 ---- System ---- File Name : screenshot.png Directory : XXX File Size : 1260 kB File Modification Date/Time : 2026:08:11 16:24:37-04:00 File Access Date/Time : 2026:08:11 16:24:41-04:00 File Inode Change Date/Time : 2026…
Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
#86Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
#87Signed 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
Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
#88“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
Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
#89This is cool, but has anyone ever needed to rewrite commit authors or dates?
Yes. Plenty of times.
Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet
#90Earlier quoted context omitted.
I have a contrarian take on this: if most people working on the codebase are using the same model, then these comments serve a very useful purpose: they tell the model's future self that despite its tendency towards this solution, it is incorrect and here's why. It encodes useful context right when the model needs it next to avoid making the same error. I imagine this style of commenting is partially responsible for…
I agree, but that information should be in the commit, which the model also has access to. Of course it's more token intensive to look through commits, but "good" models might know when some more research about a particular bit of code they find weird would be a good idea. Thoughts?