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.
oftenwrong · 3h ago
One more similar feature from a different system: PostgreSQL COMMENT
This allows you to attach text to various database objects in PostgreSQL.
I wish PostgreSQL had a feature that was more like structured key-value database object metadata that could be edited.
stephenlf · 2h ago
I love PostgreSQL COMMENT. I built a prototype app for a buddy with Supabase and added a COMMENT to every table.
codesnik · 1h ago
with supabase it is almost essential. But adding comments with migrations is somewhat tedious, unless you're writing actual sql. Like, you know, with supabase.
Pxtl · 2h ago
MS SQL has a similar feature called Extended Properties but the API is quite tedious.
I don't know why they mandate it to be the last trailer unless it's for regex reasons
_flux · 1h ago
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.
masklinn · 15m ago
> 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.
They don't need git support, but it might eventually become first-class.
arxanas · 42m ago
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?
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.
imiric · 1h ago
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?
wiktor-k · 2m ago
> 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.
adregan · 2h ago
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 complete; and new features get added at a glacial pace.
I suppose this is a long winded way of stating how annoyed I am with branch names derived from linear ticket’s titles for tracking purposes, and I wish I could use some other form of metadata to associate commits with an issue, so that I could have more meaningful PR titles (enforced that I must use the linear branch name as the title).
Though I’ll admit that it’s an issue of a size that’s more appropriate to gripe about on the internet than try to change.
dotancohen · 36m ago
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.
EPWN3D · 3h ago
Yeah I love trailers. I remember trying to use notes for certain things, and they were just kind of a pain (though I cannot remember exactly what roadblocks I hit). Trailers met my needs nicely.
cmrdporcupine · 1h ago
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.
ezst · 38m ago
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)
stephenlf · 2h ago
This is fantastic. This could really beef up CI with ticket numbers and stuff.
homebrewer · 3h ago
Also supported by Forgejo since version 10 (released in January of this year):
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.
Zambyte · 2h ago
> 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.
saghm · 2h ago
> 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.
Pxtl · 2h ago
The history-destroying problems of rebasing are a rant on their own.
Zambyte · 1h ago
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.
0x696C6961 · 3h ago
Discussion can keep happening after the commit is created.
b0a04gl · 4h ago
i use git notes pretty heavily in my current role. started as an experiment to keep track of internal code reviews without flooding the commit message or making PRs for everything. i tag every commit with context what tickets it maps to, infra constraints, links to incident threads if it's a fix. all lives in the repo. this avoids the need to grep slack or jira just to know why a line changed. nce you start using it at scale, you realise how little you need the platform UI at all. we keep talking about reproducibility in builds, but never in intent. maybe this is where that starts
smallpipe · 1h ago
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” ?
b0a04gl · 1h ago
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.
smallpipe · 1h ago
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.
mojifwisi · 1h ago
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).
noelwelsh · 3h ago
This is a UI problem, not a lack-of-knowledge problem. If Github's UI surfaced notes they would instantly get much more usage.
stephenlf · 2h ago
Yeah I wish GitHub supported these
lars512 · 39m ago
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.
lucasoshiro · 1h ago
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...
knallfrosch · 1h ago
Git notes is redundant since you need a higher-level project management tool to track features anyway. Roadmaps, feature hierarchy and non-technical details. Think of any big tracker or Jira.
I think that's fine. Unix philosophy is to focus on one thing and do that well.
pydry · 1h ago
In many cases this is because those features arent actually that useful and they are frivolities surrounding a workhorse.
cesarb · 1h ago
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.)
legends2k · 2h ago
I discovered notes from the man pages around 2020 but didn't use them as it was primarily a local repo feature. By default they don't get pushed or fetched. If course, one can configure it such that it's pushed and fetched, but that's a team decision and mine didn't vote for it.
mtillman · 38m ago
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?
paffdragon · 2h ago
I wrote a little tool for versioning based on conventional commits that uses git note for a version override. In case you want to force a specific version instead of the one autodetected, you can add a git note with the version you want.
This was useful when migrating a piece of functionality into its own repo and you want to preserve history. Adding these forced version tags into commits would be quite messy in the new repo where you switch to a new versioning scheme.
Shank · 2h ago
Why did GitHub remove support for them, and how do we get this decision reversed?
fmbb · 2h ago
I think the answer is in the link.
Making git notes more usable would make it easier to migrate from GitHub. It would make you less locked in.
olejorgenb · 4h ago
What happens of you rebase a branch containing commits with notes attached?
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.
lozenge · 1h ago
Or just put it in the commit message, after all, it is the human's description of what the commit is supposed to do
remram · 2h ago
In practice I get a lot of value out of referencing commit hashes. If I fix a problem I introduced in a previous commit (for example, commit bumped version, and I forgot to bump it somewhere), my fix will say "amends ab12cd34".
That way when I need to cherry-pick that commit, or do something similar (bump again), I can search for the hash of the commit I'm looking at to find what might be missing.
UI is worse than git-notes but no need for additional setup to sync them.
codesnik · 1h ago
you kinda doing by hand what git commit --fixup could do for you, and what git rebase -i could pick up automatically.
marcodiego · 4h ago
I bet it already exists, but what about an issue tracker in plain text maintained by git itself?
> I bet it already exists, but what about an issue tracker in plain text maintained by git itself?
I have an issue tracker file that can be added to a project. While it's technically plain text, the interface for the file ensures that a format is used, and the format ensures that changes reflect only a single ticket.
Just as long as no one edits the file using a different program, it will work just fine.
If note just for the last commit, would it easier just amend the last commit message to include any note?
Don't need remember another command option.
akoboldfrying · 8h ago
I've been using git for probably 10 years and I didn't know git notes existed. Cool!
> Here is a plea for all forges: make code review metadata available offline, inside git.
I think this will fall on deaf ears as far as commercial forges like GitHub go, since as you yourself observe:
> But much of the value of git repos ends up locked into forges, like GitHub.
For-profit enterprises are not generally excited about commoditising their own value-add. This is not a jab at GitHub -- I think GitHub do everything right (offer a great service, a very generous free tier, and make it possible to extract all your data via API if you want to shift providers). It's just the nature of any commercial operation.
esafak · 4h ago
You have to start a new service that offers that feature as one of its differentiators, then the competitors might add it (back) to catch up.
xeonmc · 3h ago
any reason why Forgejo/Codeberg couldn't/wouldn't adopt this?
Seems like a chicken-and-egg problem. Not enough people know about them because they aren't supported by most providers, and because people don't know about them, there's no pressure for providers to add support for them.
hungryhobbit · 2h ago
Coolest? It's just extra comments...
827a · 2h ago
Why would I choose to stash information like this in the git notes, versus just appending it to the commit message itself?
zygentoma · 2h ago
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.
827a · 2h ago
Ah; so notes don't impact the commit hash? That is a solid reason.
cesarb · 1h ago
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.
Izkata · 50m ago
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.
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.
https://www.postgresql.org/docs/17/sql-comment.html
This allows you to attach text to various database objects in PostgreSQL.
I wish PostgreSQL had a feature that was more like structured key-value database object metadata that could be edited.
I don't know why they mandate it to be the last trailer unless it's for regex reasons
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.
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.
- 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.
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?
Yes. The flag is perfect for scripts but it's exactly equivalent to adding the text manually.
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 complete; and new features get added at a glacial pace.
I suppose this is a long winded way of stating how annoyed I am with branch names derived from linear ticket’s titles for tracking purposes, and I wish I could use some other form of metadata to associate commits with an issue, so that I could have more meaningful PR titles (enforced that I must use the linear branch name as the title).
Though I’ll admit that it’s an issue of a size that’s more appropriate to gripe about on the internet than try to change.
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.
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)
https://forgejo.org/2025-01-release-v10-0/#new-features
https://codeberg.org/forgejo/forgejo/pulls/4753
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.
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.
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.
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.
I think that's fine. Unix philosophy is to focus on one thing and do that well.
(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.)
This was useful when migrating a piece of functionality into its own repo and you want to preserve history. Adding these forced version tags into commits would be quite messy in the new repo where you switch to a new versioning scheme.
Making git notes more usable would make it easier to migrate from GitHub. It would make you less locked in.
But I have this in my IRC logs:
That way when I need to cherry-pick that commit, or do something similar (bump again), I can search for the hash of the commit I'm looking at to find what might be missing.
UI is worse than git-notes but no need for additional setup to sync them.
https://news.ycombinator.com/item?id=43971620
And less recently:
https://news.ycombinator.com/item?id=20318947
https://news.ycombinator.com/item?id=13732598
I have an issue tracker file that can be added to a project. While it's technically plain text, the interface for the file ensures that a format is used, and the format ensures that changes reflect only a single ticket.
Just as long as no one edits the file using a different program, it will work just fine.
Don't think anyone uses it, though.
https://github.com/lelanthran/rotsit
> Here is a plea for all forges: make code review metadata available offline, inside git.
I think this will fall on deaf ears as far as commercial forges like GitHub go, since as you yourself observe:
> But much of the value of git repos ends up locked into forges, like GitHub.
For-profit enterprises are not generally excited about commoditising their own value-add. This is not a jab at GitHub -- I think GitHub do everything right (offer a great service, a very generous free tier, and make it possible to extract all your data via API if you want to shift providers). It's just the nature of any commercial operation.
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.