On Tue, 6 May 2008, Theodore Tso wrote: > > Actually, the directory rename hueristic *does* have relevance in at > least some real-world cases. For example, MySQL has plugin > directories, and occasionally the plugins get renamed, for whatever > reason. I'm not saying that directory renames don't happen. I don't even say that merges across directory renames don't happen. I *am* saying that it's not a problem. It's like data conflicts. Do they happen? Sure as hell. I can pretty much guarantee that any sane project will have more data conflicts than they will have rename conflicts (whether single-file or directory), and it's not only a problem, it's something that is absolutely *required* from a source control management system! So are data conflicts a problem? I claim that they aren't. They are a *positive* resource that you need to handle. Some of the "handling" is obviously going to be to try to avoid them, and if you get too much of them, the real "problem" is that you merge too seldom, or more commonly that you have a piece of code that is simply not done well enough, so many different people have to muck around in that area. But fundamentally, you should always have data conflicts, and they aren't a problem in themselves. They are a problem only - If they are hard to understand and see, and *unexpected*. The SCM should explain what is going on, and explain why a conflict happens (and that may perhaps mean after-the fact! I love "gitk --merge" exactly because it tends to be very good at explaining what was going on!). - If they are hard to fix. For example, one of the main problems I had with BK merging was the fact that while the megetool was wonderful, you effectively *had* to merge using it, and you couldn't sanely do an "incremental" merge where you first did a first merge job, then checked that it at least compiles, then tested it, and finally looked at the diffs from both parents and looked at whether those all made sense, and you could "refine" or fix the merge along the different phases. Of course, you hope that all merges are pretty obvious, and you can do it right in one go, but no, they're not. They'll never be. They'll never be fully automtic, but even when they aren't automatic, they'll not even be trivially to do manually. But that's OK, as long as the tool at least doesn't fight you, and lets you do whatever you want to do a part of fixing things up. Now, take a look back at directory renames. Do they happen? Yes. Do they potentially mis-merge? Yes. But are they common and/or hard to fix and handle? No. And that's why I don't think people should call them "problems". The only _real_ issue here, I think, is that git just does things differently from other SCM's. Git does a _lot_ of things differently. You get used to it. 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
