On Mon, 11 Feb 2008, Linus Torvalds wrote: > On Mon, 11 Feb 2008, Jakub Narebski wrote: >> >> Errr... index is per workarea (per checkout), and this information >> is per repository, so IMHO storing this info in an index (dircache) >> is a layering violation. Unless you were talking about pack-file-index. > > I did mean the pack-file index, not the "cache" index. > And yes, just generating the generation number when repacking is fine. It > would mean that unpacked objects don't have generation numbers, but of you > have tons and tons of unpacked objects, you have more serious problems > anyway! With generation number info in pack index, we could generate them on repack (adding some time to repack). With generation number info in separate pack-index like file, we could add generation info whenever during browsing history we get to root or to commit with generation number, saving generation numbers in the by-the-way way, generating them lazily. >> Weren't the cases of multiple roots that were difficult? Storing roots >> would help with 'hard' (if seldom happening) cases then. > The thing that worried me about multiple roots was that they make the > generation numbers essentially "meaningless" when compared across totally > unrelated commits, and might give incorrect results for generation number > comparisons as a result. > > However, I decided that if two commits really *are* totally unrelated and > don't share a commit, then: > > - yes, the generation number comparison is "meaningless" > > - BUT: we don't actually care if it's correct or not, because it will > never matter: whatever we choose to do, it's correct. Because there are > just two choices: > > (a) stop early because everything we have left is uninteresting > > (b) continue to the root because we think we might turn something > interesting into an uninteresting commit. By the way, with generation number we can always limit walk length to difference between generation numbers, or distance to root if it is smaller. -- Jakub Narebski Poland - 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
