From: Jakub Narebski <jnareb@gmail.com>
Date: Sun, 07 Feb 2010 09:15:10 GMT
Subject: Re: A generalization of git notes from blobs to trees - git metadata?
Message-ID: <m363699zn4.fsf@localhost.localdomain>
In-Reply-To: <2cfc40321002062136q64f832aesd979c9cb22f3612@mail.gmail.com>

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? :-)

-- 
Jakub Narebski
Poland
ShadeHawk on #git