←back to thread

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

(tylercipriani.com)
577 points Delgan | 3 comments | 22 Jun 25 09:14 UTC | HN request time: 0s | source
Show context
oftenwrong ◴[22 Jun 25 14:20 UTC] No.44347165[source]▶
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.

replies(10): >>44347282 #>>44347522 #>>44347679 #>>44347997 #>>44348063 #>>44348331 #>>44348367 #>>44348438 #>>44351063 #>>44352844 #
oftenwrong ◴[22 Jun 25 14:38 UTC] No.44347282[source]▶
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.

replies(4): >>44347635 #>>44347965 #>>44349322 #>>44349341 #
1. jacques_chester ◴[22 Jun 25 18:50 UTC] No.44349322[source]▶
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.

replies(2): >>44350266 #>>44352556 #
2. da_chicken ◴[22 Jun 25 21:04 UTC] No.44350266[source]▶
"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.

3. 57473m3n7Fur7h3 ◴[23 Jun 25 04:56 UTC] No.44352556[source]▶
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.