On Mon, 5 May 2008, Robin Rosenberg wrote: > > You will always find corner cases. .. and btw, this is why merging should always - be predictable (which implies "simple": overly clever merging, and especially merging that takes complex history into account is *bad*, because it's still going to do the wrong thing, but now it's going to do so much less predictable) - be amenable to manual fixes even when it succeeds (ie even if an automatic merge completes without errors, a subsequent build may find problems, and a "git commit --amend" may well be the right thing to do!) - aim for (preferrably easily-handled) conflicts when the unusual cases happen. Conflicts for *common* things are bad, because they just cause more work, and people get too complacent about fixing them. But similarly, thinking that the unusual cases should be handled automatically is also wrong - because the unusual cases are likely the ones that need some manual resolution anyway. Git will never do merges "perfectly", if only because it's fundamentally impossible to do that. But one thing git *does* do is to make it pretty damn easy to handle it. I really don't understand why people expect a directory rename to be handled automatically, when it is (a) not that common and (b) not obvious what the solution is, but MOST OF ALL (c) so damn _easy_ to handle it manually after-the-fact when you notice that something doesn't compile! Really. If you have a file that was created in the wrong subdirectory (and please admit that this is not common - it requires not just a directory rename, but also a file create in another branch at the same time), what's so hard with just doing make .. oh, oops, that was pretty obviousm, the expected source file didn't exist .. git mv olddir/file newdir/file git commit --amend and "Tadaa! All done". Your merge that was *fundamentally impossible* to do automatically, was trivially done manually, with no actual big head-scratiching involved. 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
