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

Jakub Narebski [off-list ref] writes:

David Kastrup wrote:

quoted

I must be really bad at explaining things, or I am losing a fight
against preconceptions fixed beyond my imagination.

I don't understand you, or you don't understand git. "Tree" object
in object database (in repository) represents a directory in the
working area. There was never any problem with having empty trees in
object database, or having links to empty directory in the superdir.
We don't have to change anything about object database.

I disagree here.  The object database _can_ represent an _empty_
directory that has been added explicitly, because up to now no
operations existed that actually left an empty tree.  But it can't
distinguish a _non_-empty directory that has been added explicitly
from non-empty directory that has not been added explicitly.

To wit: after the sequence

mkdir a
touch a/b
git-add a
git-commit -m x
git-rm a/b
git-commit -m x

I expect git to retain an empty directory a.  But the _tree_ now can't
be different from the tree in the situation

mkdir a
touch a/b
git-add a/b
git-commit -m x
git-rm a/b
git-commit -m x

because after step 1, the trees have identical contents, and so there
is nothing at the _identical_ step 2 that could cause different
behavior.

But in the second case, git must _not_ retain a.  So we need to record
the information that in the first case, a was added explicitly.  And
this can't be done with the current repository layout.  It doesn't buy
us anything that we _have_ a representation available for an _empty_
tree added explicitly.  We need this "added explicitly" information
for _every_ tree, not just empty ones.

And a perfectly consistent way is to make those trees with an
explicitly added directory _non-empty_, by virtue of putting a file
"." in them.  This file, of course, exists in every physical
directory, but we may or may not decide to let it be tracked by git,
using the gitignore mechanism on the pattern ".".  Perfectly
expedient.

The problems with git problems with empty directories stems from the
fact that index didn't have directories.

That basically implies that no information about directories could be
tracked in the repository.  And yes, we need appropriate information
in the index.  Again, the information whether a directory was added
explicitly.

Index is flattened version of root tree, and before subproject
support it contained _only_ info about blobs (file contents).

And the repository is a versioned and hierarchically hashed version of
the index, but its trees contain _no_ information that is not already
inherently represented by the files alone.  Permitting empty trees
would change that fundamental property, and it would not buy us the
ability to actually track directories: see above.  So it is not worth
the trouble to assign any meaningful concept to persisting empty trees
rather than make them a case for git-fsck.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum