Git Notes: Git's coolest, most unloved feature (2022) • Hacker News Board

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

#51

Post by Zambyte » Sun, Jun 22, 2025, 4:49 PM UTC

Pxtl wrote: post #36

saghm wrote: post #29

Earlier quoted context omitted.

> 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 typ…

The history-destroying problems of rebasing are a rant on their own.

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.

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

#52

Post by lozenge » Sun, Jun 22, 2025, 4:50 PM UTC

pettereriksson wrote: post #44

I think it would be interesting to add the prompt (or a summary of the prompt) as a note for each commit. This would allow the LLM to later reason about each line of code by going back and checking the notes to mine for requirements, and take those into account when changing the code again.

Or just put it in the commit message, after all, it is the human's description of what the commit is supposed to do

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

#53

Post by cesarb » Sun, Jun 22, 2025, 4:51 PM UTC

Git notes were used at the LibreOffice project to track, for each commit to the Apache OpenOffice repository (which they mirrored as a branch on LibreOffice's git repository), whether that commit was not relevant (for instance, changes to the build system which LibreOffice had long replaced with a better one), duplicated an already existing change on LibreOffice (often from many years earlier), or, the least common case, that it was accepted into LibreOffice (and which commit did the cherry-pick). You can still see it for itself at https://cgit.freedesktop.org/libreoffice/core/log/?h=aoo/tru... (that git front-end still displays notes).

(They stopped tracking these changes a few years ago, probably because the pace of changes to Apache OpenOffice slowed down to a trickle, and there's no longer much to be gained by cherry-picking these few changes.)

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

#54

Post by cesarb » Sun, Jun 22, 2025, 4:55 PM UTC

827a wrote: post #33

zygentoma wrote: post #32

Earlier quoted context omitted.

Because you would not want to write the whole git history starting from the commit you want to stash this info one everytime you want to stash additional info … Appending information to the commit itself creates a new commit and all the commits that are based on the commit will also have to change consequently.

Ah; so notes don't impact the commit hash? That is a solid reason.

Yeah, git notes are AFAIK stashed into their own hidden branch, referencing the original commit by its hash. That is, the git note points to the commit, not the opposite.

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

#55

Post by cmrdporcupine » Sun, Jun 22, 2025, 4:55 PM UTC

oftenwrong wrote: post #11

Another little-known feature is git trailers: https://alchemists.io/articles/git_trailers These are key-value structures data that can be included on a commit when it is created. These are used by some systems for attaching metadata. For example, Gerrit uses this for attaching its Change-Id.

Side note: I really miss Gerritt from my time working at GOOG, but man is its deployment story kinda crap in the 2020s. I tried to run an instance locally and was hoping to integrate it with my github hosted repo ended up just frustrated.

Is there anything equivalent -- that handles tracking changes over commits etc better than GH -- that is more actively developed and friendly for integration with GH? I hate GH's code review tools with the heat of 10,000 suns.

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

#56

Post by smallpipe » Sun, Jun 22, 2025, 4:56 PM UTC

b0a04gl wrote: post #48

smallpipe wrote: post #45

Earlier quoted context omitted.

Shouldn’t that be the commit message ? Or is the goal to also link forward in time, such as “we realised this commit introduced bug #123” ?

haha wait do you actually read long commit messages( more than a line) all the way through? like line-by-line, imo commit msg = tweet, git note = blog post.

In my line of work a bug could cost multiple millions. I do read them. I write long ones. I would love if my colleagues started writing longer ones too.

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

#57

Post by mojifwisi » Sun, Jun 22, 2025, 4:57 PM UTC

b0a04gl wrote: post #48

smallpipe wrote: post #45

Earlier quoted context omitted.

Shouldn’t that be the commit message ? Or is the goal to also link forward in time, such as “we realised this commit introduced bug #123” ?

haha wait do you actually read long commit messages( more than a line) all the way through? like line-by-line, imo commit msg = tweet, git note = blog post.

That seems more complicated than just adding the info in the commit message. It's not like Git doesn't have flags for trimming commit messages when reading them (--oneline).

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

#58

Post by pydry » Sun, Jun 22, 2025, 4:59 PM UTC

lucasoshiro wrote: post #46

There are many "Git's coolest, most unloved feature", e.g.: bisect, pickaxe, reflog, range-diff, archive, annotated tags, etc. Sadly they are often forgotten as many people thing of Git only as a glorified Google Drive...

In many cases this is because those features arent actually that useful and they are frivolities surrounding a workhorse.

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

#59

Post by _flux » Sun, Jun 22, 2025, 5:05 PM UTC

oftenwrong wrote: post #11

Another little-known feature is git trailers: https://alchemists.io/articles/git_trailers These are key-value structures data that can be included on a commit when it is created. These are used by some systems for attaching metadata. For example, Gerrit uses this for attaching its Change-Id.

I used git notes for marking which of my commits in my branch I had run the unit tests for (and thus my script would skip those). This was useful when working with open source upstream where you want the massage the branch to perfection with git rebase -i.

It seems git trailers would now be the better place to put that information.

Regarding change ids: I wish git itself had those, as then also the tooling would understand them. Identifying commits by their commit messages is fragile, in particular when you may update those for an MR. While commit id truly identifies the commit in a unique way, it is not a useful identifier when the same changes could be moved on top of some other commit.

edit: Oh it looks like they are actually part of the commit, whereas notes aren't, so it wouldn't be a good replacement for my use.

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

#60

Post by Izkata » Sun, Jun 22, 2025, 5:25 PM UTC

cesarb wrote: post #54

827a wrote: post #33

Earlier quoted context omitted.

Ah; so notes don't impact the commit hash? That is a solid reason.

Yeah, git notes are AFAIK stashed into their own hidden branch, referencing the original commit by its hash. That is, the git note points to the commit, not the opposite.

Kind of. The structure is the same and you can check it out if you want, but it's actually a 3rd directory under "refs" - the other two being "heads" (branches) and "tags". That avoids special-casing with trying to hide branches or conflicting with a branch name a user might make.