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@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
