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