31–40 of 147 posts
Earlier quoted context omitted.
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.
Why would I choose to stash information like this in the git notes, versus just appending it to the commit message itself?
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.
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.
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.
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.
Earlier quoted context omitted.
> 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 thi…
> 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…
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 don't know why they mandate it to be the last trailer unless it's for regex reasons
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.
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.