On Tue, 12 Dec 2006, Kyle Moffett wrote: > Hmm, ok. It would seem to be a reasonable requirement that if you want to > change any of the "preserve_*_attributes" config options you need to blow away > and recreate your index, no? I would probably change the underlying index > format pretty completely and stick a new version tag inside it. You should be able to promote an insufficient-version index to a new-version index that's needs to be refreshed for every entry. (And then update-index would take care of the necessary rewrite-everything in the normal way). But I suspect that the right thing is to require that the repository be created with a "commits-include-directories-not-trees" flag, and this means that you always use the extra-detailed index, and the options only affect what information is filtered out in transit between the directory object and the index. Having more information in the index is merely a potential waste of space, not a correctness issue (we have extra information for trees in the index now, remember); it just means that there are more things that will cause git to reread the file, rather than declaring it unchanged with a stat(). For that matter, it may be best for the directory objects to record what information in them is real, and keep the "what's content" mask in the index as well. If it changes over the history of a repository, you want to correctly interpret the historical commits. > Ok, seems straightforward enough. One other thing that crossed my mind was > figuring out how to handle hardlinks. The simplest solution would be to add > an extra layer of indirection between the "file inode" and the "file data". > Instead of your directory pointing to a "file-data" blob and "file-attributes" > object, it would point to an "file-inode" object with embedded attribute data > and a pointer to the file contents blob. > > I remember reading some discussions from the early days of GIT about how that > was considered and discarded because the extra overhead wouldn't give any real > tangible benefit. On the other hand for something like /etc the added > benefits of tracking extended attributes and hardlinks might outweigh the cost > of a bunch of extra objects in the database. A bit of care with the > construction of the index file should make it sufficiently efficient for > day-to-day usage. I was thinking this could be internal to the directory object, but you probably want to support hardlinks shared between dentries in different directory objects, so you're probably right that this makes sense. Alternatively, you could use a single "directory" object for the whole state (including subdirectories), making hardlinks out of the object clearly impossible, or you could use some scheme for sharing sub-"directory" objects that would imply that hardlinks are within an object (the hard part here is finding things when their locations aren't predictable by name). -Daniel *This .sig left intentionally blank* - 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