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

[Jon Seymour <jon.seymour@gmail.com>]

Another use case could be to store the contents of the man and html
trees of git, which are currently published as separate branches.

With the metadata concept, the man and html trees for each release
could be stored as metadata paths (/man, /html) of the associated
commit for each release, providing a trivial way to address and access
these trees.

jon.

On Sun, Feb 7, 2010 at 2:27 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> 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.
>