Jakub Narebski <jnareb@xxxxxxxxx> writes: > David Kastrup wrote: > >> 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 - 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
