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

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

To explain a little further why the metadata concept is different to
the resource fork or alternate data stream concept.

These two concepts were based on the idea of associating metadata with
the name of the resource and preserving the metadata along with the
resource as the resource evolved.

This is not the intent with the metadata concept. Rather, the idea is
to annotate the content (whether it be a commit, tree or blob) with
other content (a tree in the general metadata case, or a blob in the
git notes case)

The use cases I have in mind relate to caching "expensive (or
impractical) to re-derive" results from an input. So, for example,
storing /man and /html  trees for a given commit in a metadata commit
called "refs/metadata/doc" would be one case. Storing the foreign SCM
revision id that a git repo was pushed into would be another [ storing
it the commit message isn't an option because the commit has already
happened before the push ]. [ And granted: git notes can already be
used for this scenario ].

jon.

On Sun, Feb 7, 2010 at 8:41 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
> On Sun, Feb 7, 2010 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Jon Seymour <jon.seymour@gmail.com> writes:
>>
>> [cut]
>>
>>> As I see it, the existing use of notes is a special instance of a more
>>> general metadata capability in which the metadata is constrained to be
>>> a single blob. If notes continued to be constrained in this way, there
>>> is no reason to change anything with respect to its current userspace
>>> behaviour. That said, most of the plumbing which enabled notes could
>>> be generalized to enable the arbitrary tree case [ which admittedly, I
>>> have yet to sell successfully !]
>>>
>>> In one sense, there is a sense in the merge issue doesn't exist. When
>>> the maintainer publishes a tag no-one expects to have to deal with
>>> downstream conflicting definitions of the tag. Likewise, if the
>>> maintainer were to publish the /man and /html metadata trees (per my
>>> previous example) for a release tag, anyone who received
>>> /refs/metadata/doc would expect to receive the metadata trees as
>>> published by the maintainer. Anyone who didn't wouldn't have to pull
>>> /refs/metadata/doc.
>>>
>>> I can see there are use cases where multiple parties might want to
>>> contribute metadata and I do not currently have a good solution to
>>> that problem, but that is not to say there isn't one - surely it is
>>> just a question of applying a little intellect creatively?
>>
>> Are you trying to repeat fail of Apple's / MacOS / HFS+ filesystem
>> data/resource forks, and Microsoft's Alternate Data Streams in git? :-)
>>
>
> No I am not. I don't see why a metadata proposal is any more exposed
> to subversive payloads than say, use of git merge -s ours [ a
> subversive payload could be made reachable from a commit that
> otherwise merges in favour of the legitimate source - who would know?
> ]
>
> Really, I can't see why the rationale that makes a single blob used
> for extending a commit message justified can't be used to justify
> associating a metadata tree of arbitrary complexity to an arbitrary
> sha1 object. What makes maintaining a mapping to a single blob
> acceptable but maintaining a mapping to a tree unacceptable? Is there
> really any fundamental difference?
>
> jon.
>