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? -- 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