Re: Rename handling

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 19 Mar 2007, Steven Grimm wrote:
> 
> Until someone comes up with a way to make content-based rename detection 100%
> foolproof in the face of things like frequent self-references in Java or C++
> classes, it may be a necessary evil (or at least a worthwhile one.)

Try to implement it. Trust me, it will suck so badly that you'll realize 
that I am right.

File identities have *huge* problems. They are a total nightmare to 
implement well, and you'd lose a lot of the really good features that git 
has. But I suspect it's not worth trying to convince you. You really need 
to just try to do it.

I can name some of the problems:

 - you get a whole new source of really fundamentally nasty merge 
   conflicts that are really fundmanentally hard to handle.

   I have first-hand experience, and I realize that lots of people simply 
   don't even *understand* the problems. But take it from me - having two 
   different repositories create the same file independently (which is not 
   at all uncommon - patches flying around make it really easy) - is the 
   tip of a very nasty iceberg.

   Git makes merges easy in comparison. Trying to track file ID's is a 
   huge gaping hole, leading to hell. I doubt you'll find an SCM that does 
   it, and does it well.

   (Side note: in a *centralized* setup, with no branches, this isn't a 
   problem. But with branches it already becomes a nastier issue, and when 
   decentralized you simply cannot avoid it at all).

   End result: merges suck. Unless you're smart, and use git.

 - The end result depends on the path you took to get there. You're going 
   to have a really hard time re-creating things exactly, and doing so 
   from patches (which is *the* most common way actual real development 
   gets done) is basically impossible. So you end up with the meaning 
   getting lost along the way (or being added), and now where is your 
   "trustworthy" file movement logic?

I've seen both problems with BK. Bitkeeper had a nice patch application 
graphical toolkit to help some of these issues. It was really nice, but it 
was still *painful*. Not having it would be a total disaster. Except if 
you simply don't need it - like git.

The merges in particular is something that git just DOES BETTER than 
anybody else. The lack of explicit file ID information means that you can 
just fix up the conflicts in the working tree using perfectly normal 
tools, and never have to do anything special with special "merge tools". 

You may still want to use nice graphical tools to help you, of course, but 
they aren't even git-specific any more. See the whole discussion about 
visual merge tools recently, and "git mergetool", and using a random tool 
to do the merge. Realize that IF FILE IDENTITIES MATTER, none of this 
works. Suddenly, you need to have special tools that resolve the file 
identity problem (never mind the fact that quite often there *is* no 
ideal resolution and "resolving" it ends up being "pick one of the other, 
and live with it forever").

In other words, you live in a dream-world where you know you'd like to 
tell the SCM what the rename is, but at the same time you don't really 
realize what the problems with that is downstream. You think it's a great 
thing, because you've not thought the consequences through (which is 
understandable - they are subtle, and the main reason I know them is (a) 
I'm just special. My mother told me so! and (b) I've used SCM's that do 
it about as well as you can, and I've hit the problems).

		Linus