Hacker Neue

Preferences
oftenwrong parent
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.

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

jacques_chester
It's a great feature, but GitHub's parser chokes on it.

Compare:

https://github.com/jchester/spc-kit/blob/eb2de71d815b0057e20...

To:

https://github.com/jchester/spc-kit/blob/main/sql/02-spc-int...

Basically the original rendering makes me look incompetent to a casual skimmer. Plus tools like JetBrains IDEs can suss out what comments belong to what DDL anyway.

da_chicken
"The web interface to the version control system doesn't parse the here-string correctly" isn't really a criticism of the PostgreSQL extension. It's a bug in the syntax highlighting.

The COMMENT feature isn't even a good choice for a VIEW, PROCEDURE, or FUNCTION, each of which already supports comments inline in the object definition on the server. No, the main benefits are adding comments to objects that DON'T retain them, like a TABLE, COLUMN, CONSTRAINT, ROLE, etc.

57473m3n7Fur7h3
Since the project consists of multiple SQL files already, a workaround might be to split out all the “comment on” statements from each file into new files following them.

So in file 02-… you have your “create schema”, “create view” and so on. And then in file 03-… you have only the “comment on” statements that go with the things from file 02. And then file 04-… contains “create schema” and “create view” and so on, and file 05-… has the “comment on” statements for file 04-….

And in addition you could then add dash dash comments in 02 and 04 referring to files 03 and 05. And in file 03 and 05 at the top mention that these are valid SQL for PostgreSQL and that GitHub has trouble rendering them properly.

It’s a bit messy of course, but that’s why I say it’s a possible workaround rather than a great solution. Could be worth considering and trying, anyway.

stephenlf
I love PostgreSQL COMMENT. I built a prototype app for a buddy with Supabase and added a COMMENT to every table.
jaakl
I hate it. I used it to have carefully curated metadata (sources etc) to my collection of tens of tables, and someone else took backup/restore of the database and all this was lost.
codesnik
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
MS SQL has a similar feature called Extended Properties but the API is quite tedious.
eastbound
I love PostgreSQL content. I once used them in a commercial product where table and column comments would contain metadata. The product is now dead. I took this event as a cautionary tale that when we feel super empowered as developers, we often miss the market.
mdaniel
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

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

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

_flux
In my case I wanted to invalidate the notes when rearranging commits, because changing order could introduce bugs, but also have a single command that ensures that all my commits are tested before sending pull request. I think maybe it used to work that way (remove notes upon rebasing) out of the box that time, but if not, then I suspect I simply added the git commit id to the note, which can be effectively used for validity checking.

Of course, if the notes mechanism didn't exist, then I could have just used a local file.. But it's nice to see the messages in the git log.

But yeah, both kinds of keys would be useful for this purpose, depending on the exact needs.

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

chuckadams
I like the idea of conventional commits, but the lack of many useful categories is a real `chore:` to where I end up making my own, which tooling of course doesn’t recognize. The codification of something called conventional commits strikes me as kind of counterintuitive anyway.
imiric
Well, they're just commonly used commit types. I don't follow the "spec" strictly and have my own conventions as well. I don't use any tooling that reads them, and I'd probably write my own if needed.

I mainly find them helpful for sticking to atomic commits. If a change doesn't align with the commit type, or it touches too many parts of the codebase, that means it should be in a separate commit.

adregan
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
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.
Ayesh
TIL the `--trailer` CLI option. I used to edit the commit message in a text editor and manually add the trailers (which works for GitHub `Co-Authored-By`).

being able to use them with `git log` format is pretty cool.

pyuser583
I’ve wanted to use them to keep track of whether a change was done by AI.

Lack of support was a big problem.

EPWN3D
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.
stephenlf
This is fantastic. This could really beef up CI with ticket numbers and stuff.
cmrdporcupine
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.

hxtk
GitLab is actively developing native support for stacked diff workflows. CLI support for creating stacks landed in GitLab 17, and now they’re working on the code review workflow for it.

To be honest, though, I find it easiest to create several branches with Jujutsu and then manually chain the MRs. That’s what glab does under the hood with glab stack commands. Looking forward to the code review tools in a future version.

For GitHub, though, I think Graphite is the best tool I’ve looked at so far, but I use GitLab at work so I’m not the best judge of GitHub tools for lack of experience using them at scale.

cmrdporcupine
Putting stacked diffs aside, I'd frankly just be happy with the ability to track comments across different commit hashes. This is something neither GitLab or GitHub can do:

1. "Please change this" 2. <I change it, and force-push the change [cuz I don't like a messy git history]> 3. Comment keeps association with the original line and/or its new replacement.

Gerrit has no problem w/ this flow. GH and GL both can't do it.

GH wants to force you to put a pile of "fix" commits in and then either do a merge commit (eww) or squash the whole thing into one commit (not ideal in some cases).

angus-g
How does Gerrit manage this? Are the comments associated with the source content, instead of commits?
naiquevin
Gerrit uses a “Change-Id” trailer with a unique value. When you “fix up” a commit, the commit SHA changes but the change id remains the same. That’s how it can identify different commits with the same change id as patchsets of the same change.

This is based on what I remember (haven’t used gerrit in a while), so it may not be accurate.

I used gerrit in my previous job and miss using it. Would definitely prefer it over GitHub which is more popular (and convenient of course, can’t deny that).

2 More Comments →
ezst
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)

jes5199
oh I have use of that, never heard of it

This item has no comments currently.