On Tue, Feb 1, 2011 at 12:12 AM, Jeff King <peff@xxxxxxxx> wrote: > On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote: > >> > Besides being just one more directory to go up and down, it does make >> > history browsing more annoying. As much as I love git's "don't record >> > renames" philosophy, our handling of renames on the viewing side is >> > often annoying. I already get annoyed sometimes following stuff across >> > the s!builtin-!builtin/! change. This would be like that but more so. >> >> So... we do suck at something? So why not take this opportunity to >> shake yourself out of this easy comfort and improve Git as a result on >> both front? :-) > > Yes, we do suck at rename following. The problem is that it is partially > an implementation issue, and partially a fundamental issue. Obviously > --follow sucks pretty hard right now, and that could be fixed. Namely it > follows only a single file, and it interacts very badly with history > simplification. > > But even with those things fixed, there will still be annoyances. > > 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? At least that's the part that I find the most annoying with the current rename detection; having to enable the flag as I reach the end of the history for a file, often having to search through a lot of commits again. -- 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