3 ms·

That's what i don't get. I don't understand where or how you could encounter a circumstance where this would matter. This complaint seems to be an abstract th

• Groxx 16y ago
  It would matter in this situation: In the beginning: function A(){ return 1; } Now commit this in one branch: function B(){ return 1; } function A(){ return 1; } then this: function A(){ return 1; } function B(){ return 1; } function A(){ return 1; } And then this in another branch off the base: function A(){ return 2; } Now merge the two end points. Which is correct? This, assuming a purely line-based diff: function A(){ return 2; } function B(){ return 1; } function A(){ return 1; } or this, assuming knowledge of the history of events? function A(){ return 1; } function B(){ return 1; } function A(){ return 2; } In Javascript, where such code is acceptable, `A()` now returns 1 or 2. In Git, or by applying patches manually, it depends on the order in which you merge. If you merge the `B()A()` branch with the `return 2` branch and then the `A()B()A()` one, you'll get the second result. But if you merge the `A()B()A()` directly with the `return 2` branch, you'll get first one. The same set of changes producing different outcomes. In Darcs, the history between `A()`, `B()A()`, and `A()B()A()` are checked, and it's seen that the second `A()` is the "original" one, so the `return 2` is applied to that one. Which means that you won't necessarily get the same behavior merging two Darcs patches as you would merging it within the repository, where there is a history. Git behaves exactly as if you were dealing with patches. I side with Git on this, personally, but it's a valid point - you have history, why not use it?
  • saalweachter 16y ago
    You know, I suspect that in many production cases, neither merge is "correct". The example involves a lot code duplication, and a change to the block of code which was duplicated. The probable case is something like: function foo(){ do_something_complex_but_not_correct(); } with one person making the change to: function foo(){ something_else(); do_something_complex_but_not_correct(); } and then: function foo(){ do_something_complex_but_not_correct(); something_else(); do_something_complex_but_not_correct(); } in the stated two-step change, while another author makes the change to: function foo(){ do_something_complex_and_also_correct(); } The correct "merge" is going to be to apply the second change to both blocks of code, not just the first or the second: function foo(){ do_something_complex_and_also_correct(); something_else(); do_something_complex_and_also_correct(); }
    • Groxx 16y ago
      Which is why I side with explicit, patch-like behavior. Interpreting a `move-and-copy` as a `move` when there's a chunk of duplicate data that could mess things up means it's essentially doing a primitive semantic analysis of what you meant to do. It may be correct more of the time, but it can't be correct all of the time. What I "meant to do" could have been as you stated, where both should have changed. Or I could have copied the internals of a function to a new one, and made minor changes around it, and actually do wish to use that new copy as the official version. There is no way to 100% accurately detect such intent without being explicit about it, so I'd prefer something dumb and therefore extremely predictable.