3 ms·

To quote Johannes Schindelin [1] : This all just proves again that there can be no perfect merge strategy; you'll always have to verify that the right thin

• Andys 16y ago
  Amen. There's no way I ever do this in a real code base without checking that the result is what I intended.
  • ams6110 16y ago
    Yes, I also always look at diffs after a merge, and also before I commit. Several times I've caught changes that I really didn't want to go back to the branch.
• lambda 16y ago
  It's obvious that there is no perfect merge strategy. There will always be ambiguous cases, cases in which the merge algorithm doesn't have enough information to make an informed decision, or cases in which there are changes that effect lines not caught by doing line-by-line diffs. I think that the point that Zooko and Russel O'Connor are making is that there are cases in which the merge algorithm does have available to it the information necessary to make a better decision (that is, the entire history of changes, rather than just just the two changes being merged and their common ancestor), but in Git, that information isn't being taken into account. While you are never going to have a perfect merge strategy, the argument is that you can have one that is better. Some people, however, feel that the Git algorithm is good enough, and doing it the Darcs way would be slower without much benefit other than for fairly artificial examples (you have to be doing something where you move a block of code, and then re-introduce that same block back in the original place on one side of the merge, while patching that block on the other side of the merge). Personally, I've found Git's merge strategy adequate for everything I've used it for. Git has support for multiple merge strategies, so if someone wanted to implement a better but slower one as an opt-in, they could do so.