Git Notes | Hacker News Reader

Git Notes

tylercipriani.com

629 pointsthcipriani128 comments

Back when the Apache OpenOffice project was still alive, the LibreOffice project used git notes to track, for each commit to Apache OpenOffice, whether it was ignored (usually for being specific to the obsolete openoffice.org build system), redundant with a libreoffice commit (usually because the LibreOffice project had already fixed the same issue in a better way several years before), or cherry-picked into the libreoffice tree (this was the rarest case; in these last two cases, it also pointed to the relevant libreoffice commit); an aoo commit without git notes meant it had not been looked at yet. While the LibreOffice project stopped doing that a couple of years ago (probably because there was no longer anything interesting happening in the aoo repository), you can still see the branch they used to mirror the Apache OpenOffice tree, still with the git notes, at https://git.libreoffice.org/core/+/refs/heads/aoo/trunk (follow the parent links to see more, or clone the repository locally and look at that branch with gitk, which also shows the git notes).

That's a great addition, thanks. I've missed more practical examples in the original article.

Same with libav pulling commits from ffmpeg (or was it vice-versa?).

Yeah it was the other way around. As I remember it, libav devs were pretty hostile towards ffmpeg and refused to pull anything from it while the ffmpeg maintainer kept cherry-picking from libav for a long time after the fork.

IMO it's probably the primary reason why libav is practically dead now.

I've tried to use git notes over the years but unfortunately notes are tied to a specific commit hash. It's a blessing and a curse.

Works great for some types of review system, or for "tagging" things related to deploy. Notes on commits on the master/main branch, which doesn't get rebased? Awesome thing, they work.

But you can't as easily use them on branches: the moment a branch whose commits had notes is rebased, and SHAs change, good-bye notes associated with the "previous" SHAs :/

Do you need to `git config notes.rewriteRef refs/notes/commits`[1]?

[1] https://stackoverflow.com/a/14601464/96588

I had no idea this even existed, and I've run into this problem with notes myself! This seems like something that should be a default.

Seems like a standard git thing: have a process that works in a specific, but not a “helpful” way and also have a undiscoverable setting to configure said process.

Is that why people keep building UIs and wrappers for git?

Having lots of config is fine, even good, if you ship sane defaults. Frankly most OSS flunks this, and git is one of the biggest offenders.

Git has so many users that changing defaults is pretty tricky. They have done it in the past but usually over multiple release cycles with a deprecation window.

Maybe they should introduce an option to configure which set of defaults is used.

e.g.

defaults=traditional adopts current defaults (that maximise backward compatibility)

defaults=latest adopts latest recommended defaults (better out-of-box user experience, but may break things which depend on the traditional settings)

Then at least there is only one setting to change to get sane defaults.

Maybe even, defaults=VERSION to give you latest defaults as per that version.

> Maybe they should introduce an option to configure which set of defaults is used.

> ...

> Then at least there is only one setting to change to get sane defaults.

I suspect that, much like C++, there will be fierce debate over exactly what constitutes sane defaults.

Maybe there could be a "C++ style defaults" set of configuration, as default?

Ah yes, like how nginx’s defaults still like to pretend it’s early 2000s, everyone uses dialup, and nobody could possibly want their website to serve more than a handful of requests per hour.

Like Apache's default settings working well for a site that gets no more than one visitor a minute.

Yep. The default options are usually the wrong ones.

Depends. You can also see those as notes and you want to have them go away after rebase automatically so you have invalidation built in (e.g. preparing changes).

My guess is that it was originally an oversight and this option was added later, but turned off by default to avoid a "breaking change". Would be interesting to dig through the changelogs and commit history to see what the story was.

Yes, it is totally possible to guess it this way. From top of my head reference rewriting while rebase is older thought, but I'd be clueless about it apart from that rebasing is for rewriting commit references in the first place. And everything else - including git-note references - needs to be explicitly configured from that default behaviour. Which follows your argument in a broader sense, as per default no other refs are expected to get rewritten and therefore it shouldn't be different for git-notes, even if they were introduced with the configuration option to rewrite them in the first place.

Not completely sure but seems like a problem that could be solved using pre-rebase hook.

Another reason to never rebase.

Speaking of git’s plumbing, https://news.ycombinator.com/item?id=33566991 is the best guide I’ve found. It made everything simple. I didn’t realize git is just a list of blobs and trees, and that’s it. And when other people said that, I didn’t understand the meaning.

Blobs = any file, keyed by sha1. Also commits (pointer to a tree). Also trees (list of blobs).

Refs (aka branch): points to a specific commit.

I bet notes are just a blob that points to a commit.

It's way too easy to get caught up in how the data is de-duped on disk, but git is much more like a giant pile of zip files that you might think.

> I bet notes are just a blob that points to a commit.

That would make them unusable, as you’d have to read all the notes to know if a commit has one.

The notes message is a blob, but the note itself is a tree entry (the name of the entry is the commit being pointed to / annotated).

This earned a resubmitted: https://news.ycombinator.com/item?id=33767014

I have a question totally unrelated to the post, but that I finally decided to ask because of it.

In the tweet by Simon Willson at the top of the blog post, he uses the word "against":

  Started experimenting with "git notes" against a new repo [...]

English is not my native tongue, but I always take the use of this preposition as if to state an adversarial relationship between two things, a relationship of opposition between them. Therefore, sometimes I find it odd the way it is used in programming-related context. A few examples of what I mean:

  - "to program against a standard" instead of "to program based on a standard"
  - "to match against a pattern" instead of "to match the pattern onto the thing"
  - "to compare against a list" instead of "to compare with items from a list"
  - "to file an issue against the repository" instead of "file an issue at the repository"

It is possible (and very likely) that my proposed meanings are grammatically or even semantically wrong, but I feel that "against" is being correctly used in these examples because I can see a slight opposition between the two things in them, and I can understand that some people might even find an adversarial relationship there. However, in the specific case of Simon Willson's tweet, the use of "against" sounds even more off because I fail to see a repository and Git notes as being adversaries or opposite to each other. So the question is: is only me, as non-native speaker, that finds this usage (not only Willson's, but the examples too) a bit weird, or do native speaker also have similar sentiments?

I'm a native English speaker and agree that it is a slightly weird corner of the language - thanks for asking!

"Against" can also mean something like "adjacent to" or "in contact with", like "let's put the chair against this wall".

Thank you for answering. Also, I did check the dictionary before asked. As others comments pointed out, it does have a meaning of adjacency or contrast, and I guessed that this is where this usage was coming from. But still, even with this meaning, I feel a bit of an adversarial meaning. "Contrast" itself is adversarial, right? Because it comes from comparison. For instance, in "the chair against the wall", I can see the chair exerting force against the all, and the wall reacting to it with equal intensity and opposite direction (Newton's Third Law). Yet, in Willson's tweet, I can't imagine anything like that coming off of a git repository and git notes, hence my comment.

As an addendum, my first language is Portuguese, and a direct translation for this word is "contra"¹ which fits all the meanings for "against" listed in Merriam-Webster, except the adjacency one. I've never seen "contra" being used for this meaning in the wild, and I guess this is the reason I feel a bit off about it and never used it myself for that meaning when communicating in English.

¹ https://dicionario.priberam.org/contra

The physical act of comparing two objects or testing one object against another would typically involve some physical contact or proximity, so even in the case of testing some code on something, it is natural in English to by analogy use the word "against." But I think you are right in this case that "against" has significant adversarial meaning in the act of testing something: often, one introduces stress scenarios or edge cases that could cause some software to fail. Tests are in large part adversarial to the object under test.

The same with Czech (and I assume all Slavic languages?). Would be interesting to track the etymological development of this meaning.

I didn't understand if in the end you can say "contra o muro" in portuguese (about the chair). In Italian, you can.

You can say that in portuguese, it's completely correct but it seems to be much less used than "junto ao muro" as in "next to the wall/adjacent to the wall". Even being correct in this use, "contra" is a word very charged with adversarial context. Maybe that's the source of the strangeness the thread OP feels about the use of "against".

But I think a distinction between "against" and "next to" is that generally speaking, "against" implies a closer contact than just being "next to" or "adjacent to" something. Like in the chair example, "against the wall" would mean pushing the chair up as close to the wall as you can make it, whereas "next to the wall" would mean putting it close to it, but not necessarily touching it. If it was a folding chair and someone told me to put it "against the wall" I would take that to mean "fold it up and prop it up on the wall".

I can confirm that in your example the German "Stell die Sessel gegen die Wand" would be valid too and well understood, yet with a slight touch of colloquialism and old-fashioned phrasing.

Interesting how the notion of symmetric contact can be seen as a positive or negative relationship.

When it's used to describe a process it can be a physical kind of analogy:

- "to push your hand against a wall" - "to press a grinder against some metal" - "to push a mold against the clay"

There's a Newton's third law kind-of thing going on, where two things push against each other, and affect each other.

For "to program against a standard" I am imagining some malleable computer code being pushed against an unyielding form or mold until it conforms to the intended shape (i.e. standard). A similar deal as TDD (test-driven development).

It seems to me that the second and third examples are forms of "compare with and contrast against" the latter being the "relationship of opposition" you mention.

Thinking aloud, "to file an issue against a repository" grammatically resembles "to file a lawsuit against a person" and is similar in that you are registering a complaint against some problem.

Your examples:

> - "to program against a standard" instead of "to program based on a standard"

both idiomatically correct enough

> - "to match against a pattern" instead of "to match the pattern onto the thing"

the second one reads very strangely and I would not be sure what you meant, first is _very_ idiomatically correct

> - "to compare against a list" instead of "to compare with items from a list"

second one is a little strange in the sense of feeling like too many words

> - "to file an issue against the repository" instead of "file an issue at the repository"

second one feels wrong, first is correct but a little weird, "on" is probably what I would write; you can also file "with" if it is a bureaucracy, you file tax forms "with" the irs

I think the usage of against in that way is normally correct, but:

> starting to experiment with x against a new repo

Is still weird. It’s not incorrect, but it feels like the author should have used ‘in’ here.

Not a native speaker, but “Against” has many meanings, not all implying adversity/competition. https://www.merriam-webster.com/dictionary/against mentions, for example, “compared or contrasted with”, which covers the search and compare examples you gave.

Against has a rare meaning of “adjacency”. We say that we lean something against another, for example. English is weird.

git-bug's author here with my 2cts. For what it's worth, I was aware of git notes during my original design process, but I found them clunky. I realized they would not be enough on their own to do conflict resolution and I'd be better making my own data structure with regular blobs, trees and commits. But when you have that, there is pretty much no point in using notes, as that would just grow the required features on which you sit on. What if I want to port git-bug to mercurial or whatever comes next? Even metadatas (the natural point of notes) are better expressed within that same unique data structure. Additionally, you then only need to sign those commits to cryptographically lock everything.

I feel like the biggest problem is they arent fetched by default, so you dont want to put anything important as half the people cloneing your repo wont see them.

All these bad defaults around notes, and Github not showing them. makes me worry it is defacto deprecated.

I feel like this is a good default if the idea is to cram in automation metadata.

You're right, but then the name becomes misleading (it should be "Git Metadata" or something similar)

The best way out of this situation could be aliasing the feature to something else with better defaults, with a hope that gets adopted by github/gitlab and the major GUIs

Maybe just give notes a namespace if it doesn't have it already. That way you can subscribe to some and not others.

You have your users add remote.origin.fetch='+refs/notes/*:refs/notes/*' to their git config and then they're fetched going forward, but yeah it's annoying that it isn't the default for a fresh clone.

As mentioned in the post, git notes can be used for code review, and I wish code review systems would have but a front end system that end up being encoded into the source control itself: think about all the times you had to find the first commit that introduced a specific line then trace it back to the code review that approved that change. It can surely be streamlined even when external to git, but since it's coupled, to me it makes sense that it should reside together and be available offline just like every commit.

I think Gerrit does this with their Note DB: https://gerrit-documentation.storage.googleapis.com/Document...

Isn't that what git-appraise is, from the post?

Right, git-appraise seems to take that approach (I say "seems" only because I've never used it) yet it's the exception to the rule when compared to almost any other code review system for git that's out there. I'm sure there are good reasons for that being the exception but I'm also guessing that one reason being vendor lock-in.

Thank god there is Fossil [1] for the source code management (yes, management implies also making notes and documentation besides versioning) of my personal projects.

[1]: https://fossil-scm.org/

Other than SQLite, what other large projects (both closed and open source) are using Fossil?

It seems to me to fix so many of the usability issues with Git, and is much more opinionated. I much prefer opinionated tools and frameworks, the fewer (unnecessary and trivial) decisions I have to make in life the better.

Fossil seems like it would be really useful for long-running internal projects at a company. But the problem is that you need to force people to learn Fossil instead of Git, and companies (perhaps rightly) don't want to pay people to fumble around with an unfamiliar system.

Tcl/Tk are also some of the larger projects. But I guess the bulk are smaller and personal projects.

LibreCMC used to use Fossil, until they got fed up with people complaining that it wasn't Git.

Where do you host your fossil repos (or do you not centrally host them at all)?

Fossil is super easy to self host, so that what I do (on a MeLE fanless mini PC).

But there's https://chiselapp.com/ if you want a hosted solution.

For CI I self host an instance of https://concourse-ci.org/

I am self-hosting on a fairly cheap VPS. It is also possible to mirror on Github. And there is chiselapp.com

It seems like these notes aren't supported by the GUI tools (Sourcetree, Fork, etc) nor by web tools like Bitbucket, and even most commandline people don't know about them... that's quite interesting, you could use them for ASCII art, jokes, and basically silliness. And perhaps in the far future, somebody finds those notes.

I'm going to run the ticket number through figlet, then put it in a note for each commit.

What if we just reimplemented the entire github ui but everything is just stored in git?

Git notes allows comments to be attached to any line for PR.

Issues can just be a well known branch and schema. Issue comments are just git notes.

Ditto for wiki, project management and releases

Do you really want JRandomUser to be able to add notes to your repository? What additional permisioning and hooks would you need to set up and maintain to allow JRandomUser to be able to add a note to a commit but not create a new commit? ... but they need to be able to create commits on well known branches in order to add issues. Can they make it so that mirrors run out of disk space by adding notes to all the commits or extremely large issues? Should people who have the ability to force push be able to rewrite the contents of anything anyone wrote as an issue or note?

This way leads to madness. I'm sure it would be possible... but these are not headaches that I want to have.

But it would be pretty nice if people with commit access could add notes directly to commits in Github.

> Do you really want JRandomUser to be able to add notes to your repository?

Not any less than I want them to comment via the web interface.

> Can they make it so that mirrors run out of disk space by adding notes to all the commits or extremely large issues?

Better to solve that than to just not mirror the comments which is what is currently the case. You can always opt your mirror to not fetch notes if that is what you want to do.

GitHub wikis are already accessible over Git in a separate repo, as advertised via the “Clone this wiki locally” sidebar link: e.g. the wiki at https://github.com/swaywm/sway/wiki can be cloned from https://github.com/swaywm/sway.wiki.

(Of course, people have also made a variety of Git-based Web authoring tools spanning from CMSes to wikis, but I can’t say I’ve seen one that really worked out—Git’s capabilities seem too powerful to be tamed in a reasonable Web-based editor. The most elegant way to link from a website to its Git version history that I’ve seen is on Yannik Sander’s blog[1].)

[1] e.g. https://blog.ysndr.de/posts/internals/2021-01-01-flake-ifica...

It's called Fossil: https://fossil-scm.org

This is pretty much how gerrit does code review.

I've seen implementations of gitops CD pipelines use git notes as a store for release metadata and to facilitate image promotion. I like that in theory but I worry about the fact that git notes are mutable.

my current way to do this is to have build as numbered references of their original commit, and then one on top that contains the build protocol.

and thinking: part of the matter from code review outcomes, also some automated check systems have limits, so mutability may be less an issue as first anticipated. git notes might be lightweight enough to not introduce too much bureaucracy.

I’d never heard of these before but that was the usecase that immediately sprung to mind. Seems super useful and the mutability probably isn’t an issue if you’re just plugging in a little internal metadata that’s almost temporary anyway.

Wow, I’m kind of the ‘go-to git person’ in my team but have never heard of git notes. An obscure feature.

Another goody is patch-id, it identify identical patches that may otherwise have a different hash for whatever reason.

I implemented my company's SVN to Git migration, and so I was familiar with Git notes because KDE's svn2git program[1] supports using git notes for storing information.

Unfortunately, we immediately had to rewrite everything using `git-lfs` and `git filter-repo`, so all the associations were lost and we just ended up stuffing everything into the commit message instead where people could actually see it.

[1] https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git

git has a lot of stuff, even the experienced can find something new. Have you heard of git bisect yet?

Is git bisect a power user feature? I was taught git by a senior engineer early in my career and it was the first "this will save your rear" tool he showed me.

I think it depends a lot on the type of project.

If you are working on a web app that you can bisect and retest each new version in a few seconds it's an amazing tool.

If you are working on a stack of huge server apps with 1h+ build times, and complicated start up procedures you aren't going to find besect very useful at all.

1h+ build times are probably a result of not doing something about the build times like fixing #include mess, making sure there are no redundant compiles, caching and getting better hardware.

But even if your build times are that ridiculous, git bisect is still useful because it is not just a constant time improvement - having to do log(n) builds isntead of n is going to be helpful no matter how long each build takes.

I've read many times about git bisect being used effectively on the Linux kernel, so I'm not sure build times are that much of an issue...

Build time if a full kernel in mind Deen hardware is what, 5 minutes tops?

I've seen projects that take longer to link than a complete from-scratch build of the Linux kernel (and when bisecting, incremental builds do a lot for you on the later steps).

you can bisect with commands other than make

git bisect imo relies on having good commit discipline to be as useful as possible, so many novice git users will not find it useful (identifying the bad commit among "fix thing" "add stuff" "aasdfasdfljser", all of which are +1000/-1000, is not going to help with much).

So much this. Especially if you are squashing PRs, this tool is barely useful. I once tried to bisect the problem and I was able to narrow down the PR that introduced the bug, but the PR was made up of hundreds of commits squashed into one. So, we knew what PR it happened in, and it wasn't surprising because the PR touched dozens of files and hundreds, if not thousands of lines. The PR was a landing PR, in that people opened PRs into a staging branch and then eventually merged that one into the mainline.

If the commits weren't squashed, we could have narrowed down to the individual commit that introduced the (revenue affecting) bug and probably fixed the issue relatively quickly. IIRC, any git-bisect shouldn't take more than ~12ish attempts to find the breaking commit, no matter how many commits there are. At least we knew which PR the issue was affected by, but instead of just hot-fixing what was probably a one-liner, we had to either revert the entire new feature or read through all the changes to find the issue.

Squashing isn't the problem. What you should be doing is trying to make each commit the smallest possible atomic unit of change. Rebase is a useful tool for achieving this -- squashing, splitting, whatever. git add/commit -p also good for this.

This is exactly why so many of us a vehemently opposed to squashing. But in case you still have the original refs for the PR you can run bisect on that to narrow it down - assuming that the individual commits are (somewhat) consistent states that can be built.

"Power user" is relative and ill-defined, but I don't think I've ever met a git-user who at least haven't heard of git bisect.

I’ve met people who use git on a daily basis and haven’t heard of bisect or even more “common” commands like stash/rebase/reset.

There are tons of folks out there for whom git usage is a necessary but background element of some other task they’re doing, and so they know to do one or two add/commit/push style flows. I’ve had many people say to me “every so often I get git errors that I don’t understand so I just delete the whole directory and clone again”

Actually, I know a lot of people who don't know stash/rebase, but they heard of git bisect. So not sure if "more common" is a fair assessment. I wonder if there are any known statistics on that.

Definitely, but don't get to use it much.

in the end the author states "So, for now: git notes are relegated to obscurity. Forever hamstrung by an obscure and clunky interface and limited adoption—I often forget they’re there.", so after the read, I should forgot about it?

git does need a 'git bug' to track bugs though, as https://github.com/MichaelMure/git-bug does, but I prefer to have it built in git directly if possible.

Why not a issues/ directory with one file per issue ? Put comments there, track them by author as commit author. Consider them part of a branch or a release. (So a big could be fixed in a branch and not in another).

It's significantly more friction for little benefit compared to git-bug's solution. First, storing this data alongside the code means requiring everyone agreeing to use that tool (quite high ask). Then, that means that you let git merge said data in case of conflict, which leaves you two options: merge failure, or requiring the user to fix things. None of that is acceptable, and it's why many of previous attempt failed.

Thanks for the reply, interesting. Regarding everyone agreeing, isn't someone quite obliged to use the project approach to bugtracking? If there are bridges, then you could implement them for this also. Re: merging, if you merge some branch that corrects or detects some bug, you have to correct bug definition anyway ? So I'd think its better to merge it explicitly? Not saying it should be good, but I'm tempted to try it to see if it can work.

A bugtracker being "branch aware" and able to say where an issue started, where it was fixed ... can (and should IMHO) be a different concern than how the data is stored and how conflict resolution happen. By conflict resolution here, I mean: what happens when two user on different machines edit their issues and then states get merged? If you have this data into some format (let say JSON) and rely on git automatically merging, you eventually end up with corrupted formatting. Instead, you can do all that in your own branches, not pollute the normal code and not let git do any merging. Then, you can still have your bugtracker understand branches and track that information.

I understand that decoupling storage and features is useful. Regarding merge, and again I'm linking storage and functionality, but storing one file per issue would alleviate this. And two users working on the same issue would need to sync anyway. Well, maybe its foolish and would not work, I agree.

Git seems to do a lot I don’t know of. It was only last year that someone showed me git bisect, and it’s probably saved me at least a full day of stress and commit-shuffling in that time. Git either has some pretty horrible discoverability UX problems, or I just don’t question a tool I use daily.

Either way, maybe it’s time I looked at git’s man page

I use this to store my own notes on published commits. Mostly about tests that I have done.

For private commits I might just store them in the commit message if they are ephemeral. And then remove them before pushing.

The usability is okay for local work. Fiddly for pushing and pulling.

How are git notes better than just storing one or more .txt files in a repo?

You can attach them to a commit after the commit has been created, for example the code review example from the article. If you store that data in a commit at HEAD it will not be available in other branches that contain the commit.

You can see it in the log and only at the relevant commit.

No need to git show the object id of the .txt files in the repo to see the message.

According to TFA, you can add git notes to a commit afterward

True, but you can also add a .txt file and refer to the commit from the text.

They can be made after the fact without affecting existing commit sha1s.

This also makes them presumably not source controlled in the same way? I.e. is it the equivalent of a shared text file of SHA->Text mappings?

They are versioned and the log of their changes can be seen by using `git log` on the notes namespace inside `ref/`.

You can store images of Pikachu. Can your .txt files do that?

  ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣴⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣾⣿⣧⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣾⣿⣿⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡾⠋⠉⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠀⠀⣼⠃⠀⠀⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠀⢀⡏⠀⠀⠀⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠀⢸⠀⠀⠀⠀⠀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣀⣀⣠⣤⣤⣤⣤⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠀⡏⠀⠀⠀⠀⢸⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⡤⠴⠒⠊⠉⠉⠀⠀⣿⣿⣿⠿⠋⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠀⡇⠀⠀⢀⡠⠼⠴⠒⠒⠒⠒⠦⠤⠤⣄⣀⠀⢀⣠⠴⠚⠉⠀⠀⠀⠀⠀⠀⠀⠀⣼⠿⠋⠁⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠀⣇⠔⠂⠈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢨⠿⠋⠀⠀⠀⠀⠀⠀⠀⠀⣀⡤⠖⠋⠁⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⢰⠋⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⣠⠤⠒⠋⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⢀⡟⠀⣠⣄⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠉⢻⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣤⣤⡤⠤⢴
  ⠀⠀⠀⠀⠀⠀⣸⠁⣾⣿⣀⣽⡆⠀⠀⠀⠀⠀⠀⠀⢠⣾⠉⢿⣦⠀⠀⠀⢸⡀⠀⠀⢀⣠⠤⠔⠒⠋⠉⠉⠀⠀⠀⠀⢀⡞
  ⠀⠀⠀⠀⠀⢀⡏⠀⠹⠿⠿⠟⠁⠀⠰⠦⠀⠀⠀⠀⠸⣿⣿⣿⡿⠀⠀⠀⢘⡧⠖⠋⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡼⠀
  ⠀⠀⠀⠀⠀⣼⠦⣄⠀⠀⢠⣀⣀⣴⠟⠶⣄⡀⠀⠀⡀⠀⠉⠁⠀⠀⠀⠀⢸⠇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣸⠁⠀
  ⠀⠀⠀⠀⢰⡇⠀⠈⡇⠀⠀⠸⡾⠁⠀⠀⠀⠉⠉⡏⠀⠀⠀⣠⠖⠉⠓⢤⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣰⠃⠀⠀
  ⠀⠀⠀⠀⠀⢧⣀⡼⠃⠀⠀⠀⢧⠀⠀⠀⠀⠀⢸⠃⠀⠀⠀⣧⠀⠀⠀⣸⢹⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡰⠃⠀⠀⠀
  ⠀⠀⠀⠀⠀⠈⢧⡀⠀⠀⠀⠀⠘⣆⠀⠀⠀⢠⠏⠀⠀⠀⠀⠈⠳⠤⠖⠃⡟⠀⠀⠀⢾⠛⠛⠛⠛⠛⠛⠛⠛⠁⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⠙⣆⠀⠀⠀⠀⠈⠦⣀⡴⠋⠀⠀⠀⠀⠀⠀⠀⠀⢀⣼⠙⢦⠀⠀⠘⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⢠⡇⠙⠦⣄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⠴⠋⠸⡇⠈⢳⡀⠀⢹⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⠀⡼⣀⠀⠀⠈⠙⠂⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠀⠀⠀⠀⣷⠴⠚⠁⠀⣀⣷⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠀⠀⠀⡴⠁⡏⠀⠀⠀⠀⠀⠀⠀⠀⠀⢠⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⣆⡴⠚⠉⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⣼⢷⡆⠀⣠⡴⠧⣄⣇⠀⠀⠀⠀⠀⠀⠀⢲⠀⡟⠀⠀⠀⠀⠀⠀⠀⢀⡇⣠⣽⢦⣄⢀⣴⣶⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⡿⣼⣽⡞⠁⠀⠀⠀⢹⡀⠀⠀⠀⠀⠀⠀⠈⣷⠃⠀⠀⠀⠀⠀⠀⠀⣼⠉⠁⠀⠀⢠⢟⣿⣿⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⣷⠉⠁⢳⠀⠀⠀⠀⠈⣧⠀⠀⠀⠀⠀⠀⠀⣻⠀⠀⠀⠀⠀⠀⠀⣰⠃⠀⠀⠀⠀⠏⠀⠀⡿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠹⡆⠀⠈⡇⠀⠀⠀⠀⠘⣆⠀⠀⠀⠀⠀⠀⡇⠀⠀⠀⠀⠀⠀⣰⠃⠀⠀⠀⠀⠀⠀⠀⣸⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⢳⡀⠀⠙⠀⠀⠀⠀⠀⠘⣆⠀⠀⠀⠀⠀⡇⠀⠀⠀⠀⠀⣰⠃⠀⠀⠀⠀⢀⡄⠀⢠⠇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⢳⡀⣰⣀⣀⣀⠀⠀⠀⠘⣦⣀⠀⠀⠀⡇⠀⠀⠀⢀⡴⠃⠀⠀⠀⠀⠀⢸⡇⢠⠏⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
  ⠀⠀⠀⠉⠉⠀⠀⠈⠉⠉⠉⠙⠻⠿⠾⠾⠻⠓⢦⠦⡶⡶⠿⠛⠛⠓⠒⠒⠚⠛⠛⠁⠀⠀⠀⠀⠀

(not my art, taken from https://emojicombos.com/pikachu-ascii-art)

Well played :)

You can store images of Pikachu in a Git repo too.

The real answer is that the notes are not part of the commit hash and are mutable, which means that you can use them for temporary information and/or to add notes retroactively.

I experimented with using git-notes to do m-of-n multisig for git:

https://github.com/hashbang/git-signatures

"they’re cool for appending notes from automated systems (like ticket or build systems) but not really for having interactive conversations with other developers"

After reading the whole thing I was still not really clear why they not great for conversations with other developers.

You could probably even make some automated system that sync'd GitHub commit comments with the repo git notes.

You'd just have to settle on a fixed format. .

A lot of comments are mentioning using git-notes with CI/CD systems. Could someone elaborate on how this is done? Like what kind of metadata could be stored. And if there are some references, it would be really helpful.

I had never heard of this feature before but I'm having a hard time seeing why it's useful. It doesn't seem to add anything substantial beyond what a commit message already allows.

I feel like you may have missed a salient section in the blog post. Here's one sentence from that section:

> Once a commit cements itself in git’s history—that’s it. It’s impossible to amend a commit message buried deep in a repo’s log.

It’s rarely seen but possible to https://git-scm.com/docs/git-replace a commit and keep its SHA.

Could this be used instead of tags as a CI build marker? Using automated tagging of every CI build quickly adds up to thousands of tags polluting tag lists and making git slower.

I assume you'd loose the ability to work with them as tags though?

git checkout v0123

git difftool v0123 v0158

are quite useful. Didn't know it had a performance impact.

Good point. Might still be worth it though. When fetching all tags it becomes ridiculous after just a few thousand builds.

I'm only up to about 2000 but I haven't really seen slowdowns or other issues.

Maybe it’s because of some setting that always fetches tags? Just writing the branches to the console on fetch seems to take a while.

In the WebStorm IDE I can select a (git-) commit and choose "Edit Commit Message".

Is that the same thing, or perhaps implemented by using Git Notes?

No that's not the same thing, in fact that'll just do a git rebase, changing the commit itself and all commits after that one. Pretty much the polar opposite of what you want!

IntelliJ products try to provide a common interface and common naming for all "VCS" operations, whether it's Git/Mercurial/etc. In practice this obscures the actual Git operations though and requires learning yet another set of "abstract" IntelliJ-specific names for the same thing. I wish they'd stop doing that, it's really confusing and inaccurate.

What they do provide is a menu that says "Edit the commit-message". I don't need to know what commands and command-options to type on the command-line to accomplish that.

Why need git notes when we already have git commit ? Seems redundant for me.

A common use of git notes is tacking metadata onto commits.
Once a commit cements itself in git’s history—that’s it. It’s impossible to amend a commit message buried deep in a repo’s log1.

But git notes enable you to amend new information about old commits in a special namespace. And they’re capable of so much more.

The article has an answer to this in the second paragraph.

If you cherry-pick a commit, does that include its notes?

Not by default. A cherry-pick is like a one commit rebase. You're affectively rewriting the commit's changes somewhere else and so get a new SHA to reflect the new location.

Since git notes are tied to a particular SHA they don't get included.

You can configure git to do it though. As mentioned else where in the comments, here's a good stackoverflow answer explaining how:

https://stackoverflow.com/questions/14585613/is-there-a-way-...

zero added value.

let me be the opposing voice. this is a pure nerd add-on with zero value for regular users. i went through all the usage examples. even those from this thread. there is zero added value. you can link, point, store, etc. to your commit and get the same thing.

Reply on news.ycombinator.com