Re: Rename handling

On Mon, 19 Mar 2007, Steven Grimm wrote:

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