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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 21, 2007, 04:51 UTC
Message-ID: <alpine.LFD.0.999.0707202135450.27249@woody.linux-foundation.org>
In-Reply-To: <851wf2bcqy.fsf@lola.goethe.zz>

On Sat, 21 Jul 2007, David Kastrup wrote:

Show 5 quoted lines

> 
> Ok, I have now acquired enough passing familiarity with the code that
> I find part of my way around it.  Most of your patch looks like it
> caters for the S_ISDIR type not previously in use in the index (how
> about the repository?).

The object database has always had S_ISDIR (well, "always" is since very early on, when I realized that flat trees didn't cut it).

> The disadvantage is that it introduces a new data type and thus one
> has to check all the code paths to see how older versions of git will
> cater with newer data.

Take a look at the "subproject" patches - those did the same (adding the ntion of a gitlink to the index), except those also changed how the tree object looked, since now a tree could contain pointers to commits too.

> My idea of a fake zero-length file would have had predictable side
> effects:

As far as I can tell, it would have been exactly the same thing as the S_IFDIR, just instead of the S_IFDIR check, you'd have had to check the end of the filename for being '/'.

Otherwise? Exactly the same.

Except for the fact that we already supported S_IFGITLINK for subprojects (and there it matches the "struct tree" entry, so it really *does* make more sense that way), so supporting S_IFDIR was actually easier.

But hey, that's an implementation detail. I don't actually care all that much. In many ways, the "long-term" data structures are much more important than the index, the index is a purely temporary - and even more importantly - a purely local datastructure.

The more important thing is in many ways the object storage, and that's also the reason for doing the index the way I did - it more closely matches what the object storage does (ie the "index" ends up mirroring a linearized and unpacked "tree" object).

			Linus