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 - 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
