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.
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 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.
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.
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.
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.
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
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.
> 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.
> 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.
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.
> 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.
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.
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.
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.
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.
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 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.
I recently learned that GitHub uses it for an alternative to including [skip ci] for what I presume is easier removal by downstream consumers of the commit message https://docs.github.com/en/actions/managing-workflow-runs-an...
I don't know why they mandate it to be the last trailer unless it's for regex reasons
One more similar feature from a different system: PostgreSQL COMMENT
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.
MS SQL has a similar feature called Extended Properties but the API is quite tedious.
I love PostgreSQL COMMENT. I built a prototype app for a buddy with Supabase and added a COMMENT to every table.
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.
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.
This is fantastic. This could really beef up CI with ticket numbers and stuff.
Also supported by Forgejo since version 10 (released in January of this year):
https://forgejo.org/2025-01-release-v10-0/#new-features
https://codeberg.org/forgejo/forgejo/pulls/4753
That's neat, ty for sharing!
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.
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
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.
> 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.
> 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.
The history-destroying problems of rebasing are a rant on their own.
Discussion can keep happening after the commit is created.
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
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.
What happens of you rebase a branch containing commits with notes attached?
Check the notes.rewrite config options in https://git-scm.com/docs/git-notes#Documentation/git-notes.t... Also notes.rewriteRef. You can use these to configure git to carry your notes across amend/rebase.
Notes are copied to from the original to the rewritten commit by default. See https://git-scm.com/docs/git-notes#Documentation/git-notes.t... for details.
But I have this in my IRC logs:
Coolest? It's just extra comments...
Why did GitHub remove support for them, and how do we get this decision reversed?
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.
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.
Don't think anyone uses it, though.
https://github.com/lelanthran/rotsit
See this recent discussion:
https://news.ycombinator.com/item?id=43971620
And less recently:
https://news.ycombinator.com/item?id=20318947
https://news.ycombinator.com/item?id=13732598
Also checkout fossil-scm.org
Why would I choose to stash information like this in the git notes, versus just appending it to the commit message itself?
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.
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.
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.
any reason why Forgejo/Codeberg couldn't/wouldn't adopt this?
The only git-notes related issue I found is https://codeberg.org/forgejo/forgejo/issues/6385. So, probably because nobody has raised it.
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.
[dead]