On Tue, Feb 01, 2011 at 02:00:05AM +0100, Sverre Rabbelier wrote: > Heya, > > On Tue, Feb 1, 2011 at 00:12, Jeff King <peff@xxxxxxxx> wrote: > > [1] I'd be interested to see how much we can get around that slowness > > using a notes-cache. > > Do you mean something like a refs/notes/renames namespace in which we > stick notes on commits indicating that a rename indicated at that > commit, with an option of the user, after-the-fact, adding this > information manually? Yes, without the "option of the user..." bit. Basically just cache the list of renames for a given commit against its parent (which should be immutable[1]), under the assumption that it is cheaper to look up the note than it is to calculate the renames. But I would make it purely a cache, not some place for users to stick their own generated rename information (if people really want to do that, I would much rather see it go into the commit itself as a pseudo-header). -Peff [1] It's technically not immutable if you limit the pathspec, or if you have non-standard rename options. But you could define some "canonical" rename set, like all of the pairs found doing rename detection with -M90 when considering the whole set of removed files as sources and added files as destinations. That would cover the common case of people running "git log", and then more specialized detection would not use the cache. -- 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