On Jan 6, 2015, at 16:28, Johan Herland wrote:
On Wed, Jan 7, 2015 at 12:29 AM, Kyle J. McKay <mackyle@xxxxxxxxx>
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-<anything>/... 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html