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).
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 :/
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?
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.
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.
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.
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.
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?
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.
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.
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.
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.
> - "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
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.
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.
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
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.
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.
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.
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.
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.
> 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.
(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].)
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.
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.
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.
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 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).
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.
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.
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
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 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.
"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.
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.
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.
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.
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:
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.
