On Tue, Feb 01, 2011 at 01:35:16AM +0100, Erik Faye-Lund wrote: > > 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 -- 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