> I still don't see why this provides anything that isn't already supported by
> either using 'git tag', or by implementing support for notes-as-trees in the
> notes feature.
>
The intent of the metadata facility is to associate derivatives of
sha1 with the sha1 itself. If I have calculated a derivative of sha1
in the past, then let me reference that derivative using a metadata
path which I can look up knowing only the sha1 of the input and
nothing more. Yes, I could create tags of the form
${sha1}/metadata-path for all my derived results but really, this
seems an abuse of the tag facility.
Here's another motivating example:
Suppose git-svn wrote the SVN id it was synched with into structured
metadata associated with a commit, instead of into the commit message,
the equivalent of:
echo ${svn-id} | git metadata write-blob ${sha1} svn-id
Which means: for the specified sha1, read a blob from stdin and create
a metadata item with a metadata path called svn-id
To get it out again, you would write:
git metadata read-blob ${sha1} svn-id
Which says, for the given object ${sha1}, read the blob from the
metadata tree at path svn-id and write its contents to stdout.
This would avoid cluttering the commit message with the svn-id, avoid
cluttering the tag space with the info and allow any commit to be
tagged in this way.
Admittedly similar function could be achieved a little more clumsily
now with appropriate use of GIT_NOTES_REF or with note subtrees, but I
share Junio's reservations about trying to generalize notes from
blobs to trees, given way notes are currently used by the rest of
infrastructure.
jon.
--
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