On Tue, 2 Oct 2007, David Härdeman wrote: > On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote: > >also sprach David Härdeman <david@xxxxxxxxxxx> [2007.09.19.2016 +0100]: > > > But I agree, if any changes were made to git, I'd advocate adding > > > arbitrary attributes to files (much like xattrs) in name=value > > > pairs, then any extended metadata could be stored in those > > > attributes and external scripts/tools could use them in some way > > > that makes sense...and also make sure to only update them when it > > > makes sense. > > > >So where would those metdata be stored in your opinion? > > I'm not sufficiently versed in the internals of git to have an informed > opinion :) My theory was that we would provide an API for getting the "current state" listing with all of the filenames and matching contents, and leave it up to metastore to put things in the filesystem; in the other direction, metastore would build up this state, and we'd store it. People who are using this in practice would set a config option to delegate the "working tree" filesystem I/O to metastore, while other people could interact with the state as files describing the state, and could therefore specify operations that are impossible or prohibited on the filesystems that their development is done on. (This would effectively be like giving people a convenient way of setting attributes on entries in a tar file, such that they can edit it to represent a stste that they can't necessarily create in their own filesystems, and version controlling that; but more convenient, since the file contents are represented as file contents and the attributes are plain text in a listing of some sort) -Daniel *This .sig left intentionally blank*
