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

On Tue, Feb 01, 2011 at 02:00:05AM +0100, Sverre Rabbelier wrote:

Heya,

On Tue, Feb 1, 2011 at 00:12, Jeff King [off-list ref] wrote:

quoted

[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.