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

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

#61

Post by arxanas » Sun, Jun 22, 2025, 5:33 PM UTC

_flux wrote: post #59

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

One trick for running tests in rebase-heavy workflows is to use the tree hash of the commit as the cache key, rather than attach metadata the commit itself.

- That way, tests will be skipped when the contents of the commit are the same, while remaining insensitive to things like changes to the commit message or squashes.

- But they'll re-run in situations like reordering commits (for just the reordered range, and then the cache will work again for any unchanged commits after that). I think that's important because notes will follow the commits around as they're rewritten, even if the logical contents are now different due to reordering? Amending a commit or squashing two non-adjacent commits may also have unexpected behavior if it merges the notes from both sides and fails to invalidate the cache?

- This is how my `git test` command works https://github.com/arxanas/git-branchless/wiki/Command:-git-...

---

I've also seen use-cases might prefer to use/add other things to the cache key:

- The commit message: my most recent workflow involves embedding certain test commands in the message, so I actually do want to re-run the tests when the test commands change.

- The patch ID: if you specifically don't want to re-run tests when you rebase/merge with the main branch, or otherwise reorder commits.

Unfortunately, I don't have a good solution for those at present.

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

#62

Post by lars512 » Sun, Jun 22, 2025, 5:35 PM UTC

I had a good use case at Our World In Data for the public data pipeline, where one repo had the pipeline and one git-lfs repo had the build output of the pipeline. A git note added to a commit to the code pipeline recorded the hash identifying the built data.

Overall it felt elegant, and needed no maintenance after setting it up, but honestly it was never used. I think the need to look back in time was rarer than expected, and git notes being hidden by default didn’t help for awareness.

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

#63

Post by mtillman » Sun, Jun 22, 2025, 5:36 PM UTC

OP suggested that they are unused because of the awkward interface but I find that if you were taking notes in text about a release, you can easily pipe those notes to Git Notes on commit. This seems easy to me. Am I missing something?

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

#64

Post by ezst » Sun, Jun 22, 2025, 5:37 PM UTC

cmrdporcupine wrote: post #55

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

I think phabricator was doing a decent job at it while it lasted, don't know where they are at since IIRC it got abandoned and then forked.

The best way to track meta history is to have it baked into the VCS, so here Mercurial is king, and heptapod (a friendly fork of Gitlab meant to support Mercurial repos and concepts) apparently does a good job at it since it's used for Mercurial's own development (after they transitioned from mailing lists to Gerrit? to phabricator to Heptapod)

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

#65

Post by dotancohen » Sun, Jun 22, 2025, 5:38 PM UTC

adregan wrote: post #40

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.

While I mostly try to go with the flow, I do get frustrated that there are more natural places to integrate with a issue tracking system like trailers, but they are so far off issue trackers’ happy path that it’s not worth it. I think the problem is exacerbated by the fact that issue trackers follow fashion; and it’s more common that you are using the flavor of the week; and that flavor isn’t close to feature complet…

Everything you are arguing against is convention, not intrinsic. If you have a better way of doing things, do it that way. Or convince your employer to do it that way.

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

#66

Post by masklinn » Sun, Jun 22, 2025, 6:00 PM UTC

_flux wrote: post #59

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

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

Projects for which mutable changes are a unit of work are working on standardising that: https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...

They don't need git support, but it might eventually become first-class.

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

#67

Post by wiktor-k » Sun, Jun 22, 2025, 6:13 PM UTC

imiric wrote: post #50

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.

Interesting, I wasn't familiar with this feature. I'm a big fan of conventional commits, and trailers seem like a better way of adding such metadata. Is adding them manually to the commit message functionally equivalent to using the `--trailer` flag?

> Is adding them manually to the commit message functionally equivalent to using the `--trailer` flag?

Yes. The flag is perfect for scripts but it's exactly equivalent to adding the text manually.

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

#68

Post by wiktor-k » Sun, Jun 22, 2025, 6:16 PM UTC

stephenlf wrote: post #21

noelwelsh wrote: post #9

This is a UI problem, not a lack-of-knowledge problem. If Github's UI surfaced notes they would instantly get much more usage.

Yeah I wish GitHub supported these

As described in the post they did in the past: https://github.blog/news-insights/git-notes-display/

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

#69

Post by r-bryan » Sun, Jun 22, 2025, 6:17 PM UTC

Methinks Zawinski's Law of Software Envelopment finds some empirical support here.

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

#70

Post by natebc » Sun, Jun 22, 2025, 6:31 PM UTC

righthand wrote: post #18

marcodiego wrote: post #3

I bet it already exists, but what about an issue tracker in plain text maintained by git itself?

Also checkout fossil-scm.org

Yeah, I was going to say, if you think this is cool wait till you get a look at fossil!

It's even got chat!

https://fossil-scm.org/home/doc/trunk/www/chat.md