On Fri, 5 May 2006, Petr Baudis wrote: > > The automatic vs. explicit movement tracking is a lot more > controversial. Explicit movement tracking is pretty easy to provide for > file-level movements, it's just that the user says "I _did_ move file > A to file B" (I never got the Linus' argument that the user has no idea > - he just _performed_ the move, also explicitly, by calling *mv). THE USER DID NO SUCH THING. Moving data around happens with a whole lot more than "mv". It happens with patches (somebody _else_ may have done an "mv", without using git at all), and it happens with editors (moving data around until most of it exists in another file). So doing "*mv" is just a special case. And supporting special cases is _wrong_. If you start depending on data that isn't actually dependable, that's WRONG. There's another reason why encoding movement information in the commit is totally broken, namely the fact that a lot of the actions DO NOT WALK THE COMMIT CHAIN! Try doing git diff v1.3.0.. and think about what that actually _means_. Think about the fact that it doesn't actually walk the commit chain at all: it diffs the trees between v1.3.0 and the current one. What if the rename happened in a commit in the middle? The "track contents, not intentions" approach avoids both these things. The end result is _reliable_, not a "random guess". Adding file movement note to commits is simply WRONG. Why does this come up every three months or so? I was right the first time. You'd think that as time passes, people would just notice more and more how right I was and am, instead of forgetting and bringing this idiotic idea up over and over and over again. Linus - : 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