I agree that git-notes is an under-utilized idea. There's a lot of potential to add context where it matters. sideshowbarker <mike@xxxxxx> writes: > I’d be 100% happy to do the work of writing a patch to implement a solution > (a git behavior change) for this — if I could get confirmation that the git > maintainers would actually be open to reviewing such a patch. Best way to determine that in my experience is to just propose some kind of patch -- especially if the actual change is simple even if controversial. > As far as what the change would be: I realize this has been brought up > before — but it seems the obvious solutions are to “just” change git so: > > - Proposed solution #1: git auto-fetches all Notes when a repo is first cloned, > and then auto re-fetches them again for every “git fetch” or“git pull”. > > I think that auto-fetching-of-Notes would ideally be the _default_ git > behavior — but short of that, at least a new [notes] _option_ for enabling > that behavior would help. That would seem somewhat more “approachable” to > than “git config --add remote.origin.fetch '+refs/notes/*:refs/notes/*'”. This would certainly be the most turnkey approach -- but what could go wrong here? I can think of at least one potential danger: that your own notes would be wiped out on fetch if you don't remember to push them first. Laying out the risks involved with each approach would help the conversation by showing the effort you've put into the design. It's my understanding that the git-notes feature is considered a little under-baked to 'turn on' more broadly like this. There are simply too many sharp edges: - the 'push before fetch' footgun I mentioned above - merge conflict resolution workflow for the notes themselves - no 'set-and-forget' way to maintain multiple notes from multiple users off the top of my head. > - Proposed solution #2: git checks if a clone lacks Notes vs remote, and emits: > > > Your clone is behind the origin remote by N notes. To fetch the notes > > from the origin remote, run “git fetch origin 'refs/notes/*:refs/notes/*'” This is less controversial than turning it on by default, but IMO if it's not good enough to turn on by default, we shouldn't encourage its use so prevalently. > For both cases, https://github.com/sideshowbarker/git-gloss/ was used for > adding the Notes. That’s a specialized tool I wrote myself, for adding > GitHub-related Notes which look like this: > > Author: https://github.com/Jon4t4n 🔰 > Commit: https://github.com/SerenityOS/serenity/commit/9812031a02 > Pull-request: https://github.com/SerenityOS/serenity/pull/20140 > Issue: https://github.com/SerenityOS/serenity/issues/19937 > Reviewed-by: https://github.com/AtkinsSJ ✅ > Reviewed-by: https://github.com/nico Very interesting -- my systems use case for git-notes is very similar, albeit for our in-house bug tracker. Clearly it's a good idea! ;-) I'd love to see git-notes adopted more broadly, but I think there are some real problems to solve first. If others have their own thoughts/ gripes, I'd love to see such a list of deficiencies turned into a design and development plan. I'm no Git maintainer, but I would happy to provide what review I can. -- Sean Allred P.S. Sorry for the duplicate email, sideshowbarker; mu4e not-so-recently changed its default keybindings and I have STILL not recovered from this, apparently.
