Re: 4-way diff (base,ours,theirs,merged) to review merge results

"Neal Kreitzinger" <neal@rsss.com> writes:

When I need this information to resolve a merge in an area of the code that I am not very familiar with, the first thing I do is this:

  $ git merge $other
  $ git diff
  ... yikes, that is a complex conflict!

  $ git checkout --conflict=diff3 $the_path_with_difficult_conflict
  $ git diff

The output will also show the lines from the merge base.

The default style of showing the conflict we use is called the "merge" style (it originally came from the "merge" program of the RCS suite), and it only gives the two sides without the base version. It is sufficient when the person who is making the merge is familiar with the baseline history of the code (e.g. in a contributor-to-integrator pull based workflow, especially when contributors are encouraged to keep their topics focused and short). The "diff3" style that also gives the base version is needed less often in such a setting. That, and also the resulting output is much shorter, is the reason why "merge" style is the default.

When the person who is making the merge is not very familiar with the baseline history (e.g. when using Git as an improved CVS and a contributor pulls the updated upstream into his history), however, "diff3" style may be more often helpful---as you mentioned, "merge" style requires that you know your code well enough to either already know or be able to guess how the version in the merge base looked like, but by definition, pulling the updated upstream into your work will pull more stuff (because many other people are working on the code on the other side) than pulling one topic from a contributor into the integrator tree, so there may be more need to see the version from the merge base in such a workflow.

By setting the configuration variable "merge.conflictstyle" to "diff3", you would get the base version by default whenever there is a conflict.