←back to thread

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

(tylercipriani.com)
577 points Delgan | 5 comments | 22 Jun 25 09:14 UTC | HN request time: 0s | 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. hinkley ◴[22 Jun 25 18:47 UTC] No.44349302[source]▶
Can you say more? I use rebase to avoid history destruction/obscuration. Do you mean squash? If so then I agree.
replies(3): >>44349386 #>>44351985 #>>44355218 #
2. johnisgood ◴[22 Jun 25 18:58 UTC] No.44349386[source]▶
Eh, squash has its place, too. Sometimes I made a simple typo, so I make another commit that fixes the typo and I squash the last two commits.
3. GuB-42 ◴[23 Jun 25 02:25 UTC] No.44351985[source]▶
Rebase creates an entire new branch and drops the previous one, it is a form of history destruction.

Commits are actually snapshots of the entire repository, not just diffs, so even if the diff is the same, if the base is different, it is not the same commit. And when you rebase, all the old commits will stay there until you run the garbage collector, and only if they don't have a head.

4. Pxtl ◴[23 Jun 25 12:43 UTC] No.44355218[source]▶
Basically, the fact that any kind of tweaking to the history in terms of comments or grouping together related commits into a single commit changes the hashes. This means that git's normally useful ability to check "hey is commit X in the history of both branches A and B" is broken.

That's a huge usability problem with git. Even as simple as a "rebase on merge" or "squash on merge" automation makes it impractical to push your topic-branch and keep working locally on that same branch while your topic-branch is being reviewed and tested, because git doesn't retain any concept of the fact that "this block of commits has been transformed into that block of commits and so you can consider them one-and-the-same".

I'm the git sme at my office and I deeply resent the amount of time I have to spent training juniors and students around git's jagged edges.

Ideally git should have a proper in-repo objects that reify a relationship between rebased/squashed/amended/etc commits and their predecessors and exposes that when you ask things like "hey is commit X in ref Y?" it could say "no, but there is a modified version of that commit".

replies(1): >>44358176 #
5. hinkley ◴[23 Jun 25 17:39 UTC] No.44358176[source]▶
Ah. I know about this. I’m used to people meaning different things when they say history destruction.

There’s also a fun loophole where you can edit other people’s commits when doing a merge and attribute bugs to someone else. I caught someone doing this once (they were terrible at git) on account of I was the one who reviewed the code that got changed, and I specifically looked for that class of bug before approving it. Git blame and the commit history no longer agreed and I was able to show what happened.