Re: A generalization of git notes from blobs to trees - git metadata?
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Feb 7, 2010, 09:15 UTC
- Message-ID
- <m363699zn4.fsf@localhost.localdomain>
- In-Reply-To
- <2cfc40321002062136q64f832aesd979c9cb22f3612@mail.gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
[cut]
Show 21 quoted lines
> 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