Live data from Hacker News

Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet

github.com

81–90 of 111 posts

Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet

#81
post #80

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.

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

#82
post #71
post #64

Earlier 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?

If the AI (or the person) ran into a non-obvious constraint, or some externality, or there’s a plan that just isn’t implemented yet- then the comment wouldn’t be able to be divined by the AI. But yeah just pointing the AI at something and saying “write me docs” will get you something at best equally good as what’s going to be available.

Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet

#83
post #81
post #80

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.

I thought it was a semi-transparent window until I read this. The curvature makes that clear, wow!

it is a actually a screenshot, that's zorin's window transparency doing that

Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet

#84
post #80

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.

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: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.3

Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet

#85
post #80

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.

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…

To be fair, it does really look like a photo of a monitor.

Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet

#86
post #10

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.

Spreadsheet? that's a meat cleaver, not a scalpel

Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet

#87
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

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

Offtopic but, it always amuses me that the words "provably" and "probably" are one letter apart (and I frequently misread them for each other).

Re: Show HN: Git-knife – Edit commit messages, authors, and dates like a spreadsheet

#90
post #75

Earlier 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?

It doesn't necessarily have to go through commits, it can do bare git blame to see if something stands out. But otherwise agreed.
Post reply on HN