Re: A generalization of git notes from blobs to trees - git metadata?

From: Jon Seymour <jon.seymour@gmail.com>
Date: Feb 7, 2010, 03:27 UTC
Message-ID: <2cfc40321002061927m522f0c3aj7d727c47a2f0cb22@mail.gmail.com>
In-Reply-To: <201002070236.12711.johan@herland.net>

> 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.