←back to thread

Git Notes: Git's coolest, most unloved­ feature (2022)

(tylercipriani.com)
577 points Delgan | 3 comments | 22 Jun 25 09:14 UTC | HN request time: 0.494s | source
Show context
kccqzy ◴[22 Jun 25 13:46 UTC] No.44346929[source]▶
Git notes are only cool if you frequently add text to a commit after the commit has happened and visible to others.

The Acked-By and mailing list discussion link examples don't seem to be good examples. Both of these are likely already known when the commit is made. And git commit message basically can have an unlimited length, so you could very well copy all the discussions about the commit that happened on a forge into the commit message itself.

One use case I think might be a better example is to add a git note to a commit that has later been reverted.

replies(3): >>44347388 #>>44347657 #>>44349238 #
Zambyte ◴[22 Jun 25 15:22 UTC] No.44347657[source]▶
> The Acked-By and mailing list discussion link examples don't seem to be good examples. Both of these are likely already known when the commit is made.

Discussion regarding a commit (is: review) and acknowledgment of a commit cannot happen before the commit has been made.

> One use case I think might be a better example is to add a git note to a commit that has later been reverted.

Commit messages are better for this use case. When you got blame a file, it shows the latest changes for that file. If a commit reverts changes from another commit, the newer commit that reverts the older commit will show up in the blame.

replies(2): >>44347839 #>>44349298 #
saghm ◴[22 Jun 25 15:45 UTC] No.44347839[source]▶
> Discussion regarding a commit (is: review) and acknowledgment of a commit cannot happen before the commit has been made.

It can't happen before the commit on a feature branch, but it can happen before merging the commit back to the main development branch. Given that a rebase or merge commit is already frequently necessary to integrate changes from a feature branch after review is finished, I don't see why this type of info couldn't be added (or even required to exist) before merging.

replies(1): >>44347981 #
Pxtl ◴[22 Jun 25 16:01 UTC] No.44347981[source]▶
The history-destroying problems of rebasing are a rant on their own.
replies(3): >>44348333 #>>44349302 #>>44351562 #
1. Zambyte ◴[22 Jun 25 16:49 UTC] No.44348333[source]▶
That's a UI problem with git making it hard to find hidden commits (pre-rebase). The commits aren't destroyed, they are hidden. The Jujutsu CLI is nice because it fixes this UI problem.
replies(2): >>44349692 #>>44355362 #
2. leni536 ◴[22 Jun 25 19:42 UTC] No.44349692[source]▶
Rebase itself is also often used to work around UI issues of git log to present a "clean history".
3. Pxtl ◴[23 Jun 25 12:59 UTC] No.44355362[source]▶
Not only that. Git doesn't appear to have any internal link between the hidden pre-rebase commits and the post-rebase commits, which hurts its ability to copy later commits across that rebase.

Yes, you're supposed to avoid moving later commits across a rebase... but the reason you're supposed to avoid that is because git is so bad at it.