Re: [1.8.0] Tracking empty directories

Wesley J. Landaker wrote:

  1) Why WOULDN'T you want to track empty directories? We track empty files: 
isn't that just as pointless?

See http://thread.gmane.org/gmane.comp.version-control.git/52875

  2) One of git's best strengths is that it's so easy to interact with other 
SCM software, primarily because git's features are a SUPERSET of other SCMs. 

Not really.  For example, many other SCMs can store per-file comments,
arbitrary revision properties, a detailed provenance of a file, and
detailed permissions for each directory entry.

What might make git nice as an interoperability tool is that it tracks
the _relevant_ information for the history of a software project.
Example of what is not relevant information and why that matters:

 http://thread.gmane.org/gmane.comp.version-control.git/53494

All that said, I do want support for explicitly[1] tracking empty
directories, mostly for the sake of the ability to clone an svn repo
with empty directories in a simple way.

The aforementioned "share a project skeleton" use case is just a nice
bonus.

Hope that helps,
Jonathan

[1] Part of the value of the "explicitly" is to make it explicit that
early adopters are asking for trouble. :)  FWIW I imagine a transition
like this:

 1. Teach "git read-tree" and "git checkout-index" to honor empty
    directories (but not "git update-index" or "git write-tree").

 2. Teach "git write-tree" to accept empty directories.

 3. Teach "git update-index" to accept empty directories if a
    configuration item indicates so.  That configuration would
    default to false.

 4. (Maybe) add porcelain support for tracking of empty directories.
    Also teach "git diff-tree" and "git apply" about empty
    directories.

 5. Change the default to true.

An orthogonal question is how the empty directories would be stored.
I do not like the idea of a ".empty-directory" file, since what
happens when you try to import a repository with a genuine
".empty-directory" file?

Based on a quick test, currently read-tree _ignores_ empty tree
entries.  Would it be okay to say that anyone who turns on the switch
from step (3) has declared he is willing to write tree objects that
git fsck versions before v1.5.5-rc0~63 (fsck.c: fix bogus "empty tree"
check, 2008-03-04) will reject and current git might mishandle?