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. I think this has nothing to do with pack index either. Your repo may have one pack, or multiple packs, or even no pack at all. They may or may not contain commit objects, etc. The generation indexing is OTOH a repo wide issue, completely orthogonal to object packing. It has to be centralized in a single global file, or possibly one file per branch, and updated whenever new commits are added to the repository. I think the best format is to have a list of (generation_nr, commit_sha1) tuples in assending order, so whenever a fetch or a commit is performed then updating this file is only a matter of appending to it. And optimizing it even further, only merge commits (or rather merge direct parents as well as branch heads) should have their generation number cached in a file since the linear commits are trivially deduced from there. And regenerating this generation cache should not take longer than a full history walk. Nicolas - 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
