On Wed, Aug 29, 2007 at 00:07:55 +0100, Johannes Schindelin wrote:
> On Wed, 29 Aug 2007, Sam Vilain wrote:
> > Johannes Schindelin wrote:
> > >> Ok, but let's say for a moment that file properties are allowed, and 
> > >> that they are stored in the Reiser4 fashion. On filesystems that did not 
> > >> support this, it would be the only way to get at them - to go through 
> > >> the index. Unless they were also mapped to regular files, or 
> > >> filesystem-specific features somehow.
> > > 
> > > Happily, file properties as well hidden as these have _no_ _place_ in 
> > > source code that needs to be tracked.
> > 
> > But you're restricting your statements to tidy, sane code bases.  Are
> > there any particular reasons that git shouldn't be able to track insane
> > code bases, with attributes etc?  It sure would shut up a whole load of
> > people.
> 
> To the contrary.  People having those insane setups seem to be unable to 
> admit it.  And I'm sure you saw some on this very list, like me.  They 
> never shut up, they only get louder.

Whether it's insane depends on whether you want to keep git purely for
source control -- in which case they are definitely insane -- or want to
allow git to grow to a tool useful for other cases, like tracking content of
/etc, whole filesystem images and similar stuff -- in which case most of
those setups are not insane at all.

Personally I would vote for a middle ground. To keep core git simple, but to
provide enough hooks to build the other tools on top of it. Enough hooks in
this case would mean (at least the way I can imagine as workable) hooks to
run when transfering files between worktree and index and place for the hooks
to store the extra tracked information. This place could be some of special
named file (.gitxattrs or anything) which would be updated in index by the
hook, special index entries somehow related to individual filenames and/or
headers prepended to the blobs and trees. Any of those methods can be used
for storing permissions, acl, extended attributes and other random stuff and
different ones could be used by different hooks at the same time.

Each of those methods has it's advantages and disadvantages. The special
files are easiest to store if the hook is not available or can't represent
the data in given worktree -- simply make the special files regular. The
entries attached to files (which are equivalent of extended attributes) would
work with standard merge on them (because they are handled individually) and
the headers to files would probably require least changes to git (I believe
they are implementable for files with git as is using the hook provided for
keyword expansion (or is it not there?)).

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>