On Mon, 19 Mar 2007, Steven Grimm wrote: > > Err, then I am *going* to consider it a failure of the tool. Sure. And then realize that nothing is perfect. Git is just *closer* to perfect than any other SCM out there. That doesn't mean that you can never find cases where you consider it failed. It just means that it fails less than the alternatives. To be perfect, an SCM would have to be able to infer a higher meaning. Who knows - maybe that will happen in a few centuries (or decades, but AI has not had a good track-record so far). Git tracks exactly the stuff that does *not* require it to infer higher meanings - purely data. I personally consider it one of gits greatest strengths: it never matters *how* you get to some state, or what tools you used (patches, imports from other SCM's, "git mv" with intelligent developers, "git mv" with total clutzes, "plain mv", random monkeys typing, whatever). Git tracks not "intent", but "hard data". The fact that git then can use that unambiguous hard data to show you interesting patterns is a big deal. But you need to realize that it's an even *bigger* deal that git only traffics in hard data that leaves absolutely no room for mistakes. Git simply doesn't *care* whether you applied a patch to create the rename, or whether you imported the series from a system that doesn't track renames, or whether you just forgot to do "git mv". You should be really really happy about that. Btw, the reason -M isn't on by default is not that it's more expensive in CPU-time (it is, but quite frankly, you will never really see that effect in practice). No, the real reason is that if you use "-M" and actually see renames, traditional tools no longer understand the patches. And sadly, there are still too many unwashed and ignorant people out there to make the default patch format be git-specific. When the revolution comes, and we can shoot everybody who uses anything else, we'll turn -M on by default. Don't despair, comrade! Linus - 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