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

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,