Re: [RFC PATCH] Re: Empty directories...

[Tomash Brechko <tomash.brechko@gmail.com>]

Hi David,

On Thu, Jul 19, 2007 at 13:31:50 +0200, David Kastrup wrote:
> core.excludefile: .

Really nice idea to give directories 'DIR/.' name.  I'm sure there are
several other ways to implement your proposal.  But why to put in in
Git itself?  Decomposition and abstraction principle tells me that
this should go to some other place.

Please consider this: I myself use Git to track my own local projects,
and for this usage you proposal have no value for me, i.e. as a
_Source_ Code Management system Git is rather complete.  But I also
track /etc and ~/ in Git, and for this I'd love to have directories,
permissions, ownership, other attributes, to be tracked.  I have Perl
script wrapping Git that allows me to filter tracked paths by full
regexps instead of Git's file globs, and also to filter out too big
files assuming that they are binary anyway.  Most people solving the
same problem moved further and implemented tools to store part of file
system state (permissions and ownership) in a textual representation,
to track that in Git.  I'm sure you've seen such posts in the list.
And my point is that rather than building the support for all of it
into core Git, and then implementing sophisticated configuration to
disable parts of it, wouldn't it be better to have a separate tools
orthogonal to Git itself?

At the extreme case (probably not really seriously), consider the
following design: there are two layers, file system layer, and
contents layer.  On checkout file system layer creates (or examines
existing) directory tree along with all files and their file system
state (permissions, ownership, ACLs, attributes, ...), and then asks
contents layer to update the contents.  This way layers are
independent, and file system layer may be implemented on top of pure
contents tracking.  File system layer may be extended to be made
particular OS/FS dependent if some development team wishes so.  Even
hard links may be supported: since file system layer may deside to
remember that two paths really reference the same inode
(i.e. contents), contents layer may be asked to update the data only
once with either file name/descriptor.

This, BTW, is why I think not tracking file attributes when
versioning, say, /etc, is not a big loss.  When I will move to the new
system, I will mostly be interested in contents diffs of the same
configuration files in /etc.  I will trust their new attributes, and
will not want to restore them to what they were on the old system.

So the essence of my objection is that we should not pollute core Git
with file system state tracking more than it's required to know where
to put the contents to.  Everything else should go elsewhere.

Again, I'd love to have your proposal be implemented, but only in a
way that won't interfere with pure SCM's operations.


-- 
   Tomash Brechko