Confusing "bzr log" as result of merges

[Eli Zaretskii <eliz@gnu.org>]

Sometimes, you want to know when was a certain file last modified.
This is when "bzr log" is useful, if invoked with the name of that
file.  However, it looks like the way we merge other branches, and in
particular emacs-23, makes this harder than it needs to be.

An example of this difficulty is below:

With the current trunk, type this command:

  bzr log -l1 --line --include-merges src/xdisp.c

You will see this as output:

  104201: Glenn Morris 2011-05-12 [merge] Merge from emacs-23; up to r100577.

However, neither "bzr status" nor "bzr diff" will show any changes for
xdisp.c in that revision.  The reason, it seems, is this:

  bzr log -l2 --line --include-merges src/xdisp.c

   => 104201: Glenn Morris 2011-05-12 [merge] Merge from emacs-23; up to r100577.
        99634.2.937: Eli Zaretskii 2011-05-09 Backport revisions 103939.1.41..103939.1.44 (inclusive) from trunk (bug#8623)

and revision 99634.2.937 indeed made a few changes to xdisp.c.  But
that version was merged to the trunk much earlier, in revision 104021,
and "bzr annotate" still shows that the changes attributed to revision
99634.2.937 were made in 103939.1.41, not in 104201 nor in 99634.2.937:

  103939.1.42  eggert@cs.ucla.edu            20110425 |       it->dpend = v->contents + v->header.size;

I think this happens because bzr is smart enough to know that the
revision which changed this line is already on the trunk, and so it
doesn't record any changes for xdisp.c in the merge-commit or 104201.
Bazaar is doing TRT, but the net result for the user is confusion and
extra time spent when trying to figure out who made this specific
change and why.

What can we do to avoid this confusion as result of merges?  And why
was 99634.2.937 merged to the trunk, even though the log message
clearly says it's a backport?  If we avoid merging such backported
revisions, will this problem go away?