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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
