From: Kyle J. McKay Date: Wed, 07 Jan 2015 01:51:15 GMT Subject: Re: [PATCH v2 2/2] t/t3308-notes-merge.sh: succeed with relaxed notes refs Message-ID: <74EB0B94-0FD1-4AD2-9493-20DB02FC5071@gmail.com> In-Reply-To: On Jan 6, 2015, at 16:28, Johan Herland wrote: > On Wed, Jan 7, 2015 at 12:29 AM, Kyle J. McKay > wrote: >> Perhaps that is the crux of the issue. There is no git notes- >> plumbing >> command where the git notes command continues to apply restrictions >> but the >> vaporware notes-plumbing command allows anything just like update- >> ref does. > > Good observation. From my POV, as people start creating tools that use > notes in a more structured manner (than as free-form plain-text > appendages > to commit messages), the sharp and pointy bits (and bugs) of the > interface > come into view. This applies to the safety features being discussed > in this > thread, but also IMHO to the other things being currently discussed/ > fixed > in the notes code: > [...] > I haven't considered that we might at some point be > better off splitting out a separate plumbing command for manipulating > notes. However, I'm not sure we're there, yet. The problems raised so > far do not IMHO warrant the creation of a whole new plumbing command. > Instead, we can still keep fixing and improving 'git notes'. > >> 1) There's no simple way to store remote notes refs outside the >> refs/notes >> namespace in such a way that they can be used with git notes >> commands. >> >> 2) People who want to experiment with using git notes storage as a >> basis for >> building some new feature are forced to store their refs under the >> refs/notes namespace even if that does not make sense for the >> feature when >> what's stored in the notes tree is not intended to provide any >> content that >> is directly meaningful to the user. > >> A whitelist solves issue (1) but is no help for issue (2) unless some >> additional additional part of the refs namespace were to be also >> whitelisted. Perhaps something like refs/x-/... in the >> same vein >> as the various IETF standards for experimental names. > > Alternatively (or additionally), for issue (2), we could add a > --disable-ref-safety option to 'git notes', to explicitly disable the > safety checks for "experimental" use. I like that. Sort of a poor-man's git notes-plumbing option. And there is precedence for this sort of thing as recently (v2.2.0) git hash-object learned a "--literally" option to bypass checks it would otherwise normally perform. -Kyle