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

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

Dear Git fellows,

A year or so ago I too would strongly advocate the need of tracking
empty directories, permissions et al., it seemed so "natural" and
"plain obvious" to me back then.  But since that time I learned to
appreciate the "contents tracking" approach, and now view directories
(paths in general) only as the means for Git to know where to put the
contents on checkout.  This, BTW, is consistent with how Git figures
container copies/renames.

No doubt mighty Git developers can add support for empty directories,
manage to stay backward compatible, think out consistent user
interface etc.  But there's no end to how much information one may
want to store in Git to make it "_file system_ contents tracking
software".  Starting with empty directories, one may argue then that
certain installation trees also need particular file ownership, so
lets store user/group names like tar does.  It was mentioned already
in this thread that in addition to 'rwx' we also would have to store
ACLs (some OSes have only one of these concepts, some both), SELinux
security contexts, perhaps other arbitrary file attributes that may be
part of file system state.

Wouldn't it be better to preserve Git as a contents tracking system,
and add some tools on top of it that can translate file system state
into textual (or binary) form, so it can be stored in current Git?
And then use this textual representation to restore actual file system
attributes/layout on checkout?  And the only change in Git itself
would be some more hooks, for instance one hook before checking out
over the old work tree, and one after the checkout.  Or one can simply
wrap certain Git commands to implement such hooks.

In any case, no one is going to be against the new feature if it won't
break anything for those of us who find the pure contents tracking the
right thing.  And storing empty directories by default may not be
natural for everyone.  So before going into technical details of how
this can possibly be implemented, could someone answer the following:

1 Is Git going to track directories _always_?  Looks like not, because
  in this thread there seems to be a distinction between 'git add DIR'
  and 'git add DIR/FILE', i.e. not everyone is sure if in the last
  case Git should track DIR or not.

2 If Git will track only explicitly mentioned directories, then what
  about recursive operations?  Will it add only files by default, or
  directories too?  Perhaps there will be some --add-dirs option to
  'git add'.

3 Since in certain recursive operations one will want to affect
  directories too, how .gitignore will look?  Most files have a notion
  of extension, so me may say '*.o', but with directories things a bit
  more complicated.  One would want to say "exclude DIR2 only if under
  DIR1 at any hierarchy depth", i.e. exclude paths matching
  qr%DIR1/(.+/)?DIR1/%, and shell wildcards aren't that expressive,
  '*' doesn't cross hierarchy.  Note that we live without this now,
  but this will be the next "natural" demand once directories become
  first class citizens.


This list is surely incomplete.  The point is that before we go into
technical details, let's consider what exactly we are going to
implement, how this will affect current usage model, how (empty)
directory handling will extend to future similar demands, etc.  My
fear is that once some patch is around, it's very tempting to accept
it.  And once it is in, it's almost impossible to remove the feature
later.


Regards,

-- 
   Tomash Brechko