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

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

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.
And I'm not knocking those decisions; I think they made the right
tradeoff. But that doesn't mean we don't pay the cost for that tradeoff.

And no matter what your model, renames can be annoying. On-going topics
will have a painful rebase or merge. And people looking at history will
have to deal with the code-base having different names at different
points. Yeah, you can say it's all just "content", but the filenames we
put things in are actually useful.

So I don't think it's wrong to say "renames are a pain, and so should
not be done lightly". I do think it's wrong to say "renames can't be
done"; I just the cost needs to be considered.

-Peff

[1] I'd be interested to see how much we can get around that slowness
using a notes-cache.