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@xxxxxxxxx> wrote: > On Sun, Feb 7, 2010 at 8:15 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> Jon Seymour <jon.seymour@xxxxxxxxx> 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. > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html