如果git可以弄清楚如何合并垂直（线条）更改，为什么不合并水平（字符）更改？

Question

If commit Apple puts 'a' on line 1 and commit Banana puts 'b' on line 3, git can just merge those commits together no problem, but if 'a' is at the beginning of line 1 and 'b' is at the end 9 characters across, it chokes and has no idea how to merge them and you have to do it manually.

Why can't it figure this out?

Even if the same line is edited like this:

original commit:       <question1 states="AZ,OH">
commit Orange line 25: <question1 states="AZ,IN,OH">
commit Pear line 25:   <question1 states="AZ,OH,TX">

Git merge can't figure out to put IN before OH and TX after, but I as a human can easily see how to do that, and I've used comparison editors (like KDiff3) that have pointed out for me which exact characters changed (color-coded), whereas git only shows changes by full lines.

KDiff3 example:

I just can't tell if git thinks OH in Orange changed to IN,OH or if it's just too much processing to check if IN was only added before OH... but maybe there's a better merge tool that can figure this out?

Answer 1

Git's built in merge algorithm uses Git's built-in diff, which is line oriented. It's really that simple: it sees two diffs, one of which says "replace line A with line B" and one of which says "replace line A with line C" and the two replacements differ => conflict.

If you provide a custom merge driver, you can run your own diffs and do your own merging. It's not at all trivial, though. In this particular case, a two-pass algorithm (first, find changed lines; second, see if changed lines can be handled as changed characters instead) might work.