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

On Tue, Feb 01, 2011 at 01:35:16AM +0100, Erik Faye-Lund wrote:

quoted

It will still be _slower_ to turn it on all the time, for one[1]. And
that's due to fundamental design decisions of the git data structure.

Does it really have to be? I mean, for whole-file rename-detection, if
we say that we automatically enable rename-detection (by default) as
we reach the first commit that doesn't have a given tree-entry, then
it would only kick in as we're about to terminate the log-output. And
since we're usually reading through a pager, it should means that it
takes a little bit more time before the user knows he's at the end of
the log. It shouldn't really affect the throughput of the data before
the point that becomes an annoyance, right?

That's not quite true. You may be following not just a single file, but
some arbitrary pathspec. Any time there is a file creation event that
matches that pathspec, you will want to rename-detect any possible
sources for that created file, and add them to the list of interesting
paths.

But yeah, we don't have to do rename detection for every single case. So
the slowness may turn out to be not that bad. When I had
arbitrary-pathspec following this summer I thought I did some numbers,
but I don't remember the results and I can't find them on the list.

-Peff