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

On Sat, 21 Jul 2007, David Kastrup wrote:

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