On Tue, 2 Oct 2007, David H=E4rdeman wrote:

quoted text
> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
> >also sprach David H=E4rdeman <david@hardeman.nu> [2007.09.19.2016 +0100]=
:
quoted text
> > > But I agree, if any changes were made to git, I'd advocate adding
> > > arbitrary attributes to files (much like xattrs) in name=3Dvalue
> > > 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?
>=20
> 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"=
=20
listing with all of the filenames and matching contents, and leave it up=20
to metastore to put things in the filesystem; in the other direction,=20
metastore would build up this state, and we'd store it.

People who are using this in practice would set a config option to=20
delegate the "working tree" filesystem I/O to metastore, while other=20
people could interact with the state as files describing the state, and=20
could therefore specify operations that are impossible or prohibited on=20
the filesystems that their development is done on.

(This would effectively be like giving people a convenient way of setting=
=20
attributes on entries in a tar file, such that they can edit it to=20
represent a stste that they can't necessarily create in their own=20
filesystems, and version controlling that; but more convenient, since the=
=20
file contents are represented as file contents and the attributes are=20
plain text in a listing of some sort)

=09-Daniel
*This .sig left intentionally blank*