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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 20, 2007, 00:33 UTC
Message-ID: <alpine.LFD.0.999.0707191726510.27249@woody.linux-foundation.org>
In-Reply-To: <alpine.LFD.0.999.0707191706120.27249@woody.linux-foundation.org>

On Thu, 19 Jul 2007, Linus Torvalds wrote:

> 
> That's physically impossible with the git data-structures (since there is 
> no way of saving "this directory was added empty" in the tree structures, 
> nor any point to it), so I think it's just insane rambling.

Of course, it's physically *possible* to have a tree that contains two entries for the same name: first the "empty tree" and then the "real tree", and yeah, in theory you could track things that way.

So I guess the "physically impossible" was a bit strong. You'd have to have a totally insane format, and you'd have to violate deeply seated rules about what trees look like (and the index too, for that matter: we'd have to do the same for the index, and keep the S_IFDIR entry alive despite having other entries that are children of it), but it's *possible*.

It's just a really bad idea.

So to be sane, when you add files, the empty directory entry has to go away. Otherwise you could have two very different trees that encode the same *content* (just with different ways of getting there - depending on whether you have a history with empty trees or not), and that's very much against the philosophy of git, and breaks some fundamental rules (like the fact that "same content == same SHA1").

In fact, that may be the best way to explain why it's *not* an option to have "empty trees remain empty trees if we remove the last file from them": git fundamnetally tracks "content snapshots", and anything that implies the content containing any history is against the rules.

So the whole notion of "remembering" whether a directory was added explicitly as an empty directory or not is just not a sensible concept in git.

		Linus