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

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

On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote:

quoted

quoted

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.