Re: [1.8.0] reorganize the mess that the source tree has become

[Jeff King <peff@peff.net>]

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@peff.net> 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.