A merge should always be done by rebasing the to-be-merged material onto the target-of-merge branch. This way not only is the history linear (and thus understandable, rather than some indecipherable "git log --graph" ball of yarn) but the individual changes are properly re-worked to fit into the target.
When we go back and view those changes, they are all in terms of this codebase, not the original changes that do not apply cleanly to this codebase. That's a big problem with git merges: the merge itself is one huge jump that collapses all the changes. The original changes are traceable in its lineage through the second parent, but those are the verbatim original changes, not the merged changes.
When we go back and view those changes, they are all in terms of this codebase, not the original changes that do not apply cleanly to this codebase. That's a big problem with git merges: the merge itself is one huge jump that collapses all the changes. The original changes are traceable in its lineage through the second parent, but those are the verbatim original changes, not the merged changes.