When you do a simple bzr merge that has no conflicts, then view the commit log, it shows all of the modifications done by the merge as if they were applied as one giant squashed patch. This gives the appearance that you applied a giant patch instead of just merged another branch, and makes reading the merge quite difficult since you can not separate any manual changes that were required to complete the merge and get it to compile from the upstream changes being merged from the other branch.
When you do a merge in git and look at the log, the diffstat and diff only show any manual changes you made during the merge, so if the merge was clean and had no conflicts and you did not have to manually modify any files, the diff is empty so it is clear that you made no modifications beyond those documented in the commit history of the merged branch.
To give a specific example:
mkdir foo
cd foo
bzr init
echo foo > a
bzr add a
bzr commit -m "added a"
bzr branch . ../bar
cd ../bar
echo bar > b
bzr add b
bzr commit -m "added b"
cd ../foo
bzr merge ../bar
bzr commit -m "merged bar"
bzr log -p
The log output shows a diff for rev 2 adding "bar" to file b. Doing the same thing with git shows no changes done by the merge commit, since it was the parent commit that added the file b, not the merge commit. In effect, you see the change in both the original commit and the merge commit with bzr ( rev 2 and 1.1.1 ), but only in the original commit with git. It is confusing to see the same diff duplicated in two revisions, and makes reviewing the merge difficult or impossible.