On Tue, 12 Dec 2006, Kyle Moffett wrote:

quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html