Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > 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). Then I think I have a bit of a problem: I should think that S_ISDIR in the repository presumably marks a tree object (still very fuzzy around the concepts here). An explicitly checked-in directory (under my scheme always named "." inside of its tree) would presumably also have S_ISDIR in the repository but behave quite differently. > 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 '/'. Relative file name of ".", more or less. Both names satisfy S_IFDIR in the filesystem, though. > Otherwise? Exactly the same. > 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). I still have to get enough of a clue about the object store to see how this pans out. I would not want to have the "." objects marked as type "tree" and empty if I can avoid it. It seems unclean, would need extra case separations all over the place, violate the "empty trees evaporate" property and also waste a good place for tracking permissions or other attributes in future. -- 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
