[HN Gopher] Git Notes: Git's Coolest, Most Unloved Feature
___________________________________________________________________
Git Notes: Git's Coolest, Most Unloved Feature
Author : thcipriani
Score : 253 points
Date : 2022-11-27 20:17 UTC (2 hours ago)
(HTM) web link (tylercipriani.com)
(TXT) w3m dump (tylercipriani.com)
| reilly3000 wrote:
| 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.
| aidos wrote:
| 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.
| hakre wrote:
| 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.
| cesarb wrote:
| 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).
| hakre wrote:
| That's a great addition, thanks. I've missed more practical
| examples in the original article.
| LukeShu wrote:
| Same with libav pulling commits from ffmpeg (or was it vice-
| versa?).
| amelius wrote:
| How are git notes better than just storing one or more .txt files
| in a repo?
| civopsec wrote:
| You can store images of Pikachu. Can your .txt files do that?
| nerdponx wrote:
| 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.
| m12k wrote:
| According to TFA, you can add git notes to a commit afterward
| amelius wrote:
| True, but you can also add a .txt file and refer to the
| commit from the text.
| emmelaich wrote:
| They can be made after the fact without affecting existing
| commit sha1s.
| quickthrower2 wrote:
| 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?
| civopsec wrote:
| They are versioned and the log of their changes can be seen
| by using `git log` on the notes namespace inside `ref/`.
| kryptiskt wrote:
| 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.
| hakre wrote:
| 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.
| [deleted]
| aerovistae wrote:
| 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.
| dorian-graph wrote:
| 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.
| erik_seaberg wrote:
| It's rarely seen but possible to https://git-
| scm.com/docs/git-replace a commit and keep its SHA.
| pyrolistical wrote:
| 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
| shagie wrote:
| 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.
| nerdponx wrote:
| But it would be pretty nice if people with commit access
| could add notes directly to commits in Github.
| almog wrote:
| 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.
| pokstad wrote:
| I think Gerrit does this with their Note DB: https://gerrit-
| documentation.storage.googleapis.com/Document...
| wffurr wrote:
| Isn't that what git-appraise is, from the post?
| almog wrote:
| 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.
| bawolff wrote:
| 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.
| quickthrower2 wrote:
| All these bad defaults around notes, and Github not showing
| them. makes me worry it is defacto deprecated.
| jayd16 wrote:
| I feel like this is a good default if the idea is to cram in
| automation metadata.
| blondin wrote:
| 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.
| graypegg wrote:
| 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
| alkonaut wrote:
| 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.
| tjoff wrote:
| 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.
| alkonaut wrote:
| Good point. Might still be worth it though. When fetching all
| tags it becomes ridiculous after just a few thousand builds.
| mfontani wrote:
| 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 :/
| YetAnotherNick wrote:
| Not completely sure but seems like a problem that could be
| solved using pre-rebase hook.
| l0b0 wrote:
| Do you need to `git config notes.rewriteRef
| refs/notes/commits`[1]?
|
| [1] https://stackoverflow.com/a/14601464/96588
| metafunctor wrote:
| 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.
| hakre wrote:
| 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).
| nerdponx wrote:
| 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.
| hypothesis wrote:
| 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?
| TylerE wrote:
| 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.
| stevage wrote:
| Yep. The default options are usually the wrong ones.
| lrvick wrote:
| I experimented with using git-notes to do m-of-n multisig for
| git:
|
| https://github.com/hashbang/git-signatures
| smartmic wrote:
| 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/
| gpanders wrote:
| Where do you host your fossil repos (or do you not centrally
| host them at all)?
| smartmic wrote:
| I am self-hosting on a fairly cheap VPS. It is also possible
| to mirror on Github. And there is chiselapp.com
| samwillis wrote:
| 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.
| nerdponx wrote:
| 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.
| LukeShu wrote:
| LibreCMC used to use Fossil, until they got fed up with
| people complaining that it wasn't Git.
| smartmic wrote:
| Tcl/Tk are also some of the larger projects. But I guess the
| bulk are smaller and personal projects.
| michaelmure wrote:
| 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.
| synergy20 wrote:
| 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.
| makapuf wrote:
| 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).
| michaelmure wrote:
| 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.
| diarrhea wrote:
| Wow, I'm kind of the 'go-to git person' in my team but have never
| heard of git notes. An obscure feature.
| ddevault wrote:
| git has a lot of stuff, even the experienced can find something
| new. Have you heard of git bisect yet?
| eropple wrote:
| 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.
| krick wrote:
| "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.
| akerl_ wrote:
| 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"
| krick wrote:
| 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.
| SimonPStevens wrote:
| 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.
| MartinodF wrote:
| 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...
| emmelaich wrote:
| Another goody is patch-id, it identify identical patches that
| may otherwise have a different hash for whatever reason.
| sillysaurusx wrote:
| 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.
| bombcar wrote:
| 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.
| metadat wrote:
| This earned a resubmitted:
| https://news.ycombinator.com/item?id=33767014
| civopsec wrote:
| 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.
| bartvk wrote:
| 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.
___________________________________________________________________
(page generated 2022-11-27 23:00 UTC)