Re: Confusing "bzr log" as result of merges

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sun, 22 May 2011 11:14:40 -0300
> 
> > 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:
> [...]
> > What can we do to avoid this confusion as result of merges?
> 
> Easy: if it hurts, don't do it.

??? You mean, don't use one of the most useful and efficient commands
in bzr?

> The log command you used does not tell you "the latest revision that
> changed src/xdisp.c"

It does, in all other circumstances.  It just goes by the metadata,
not by source lines.

> so if you're looking for this latest revision, use something else,
> like bzr annotate.

"bzr annotate" is dog slow, especially on a long and veteran file such
as xdisp.c, even if you limit the range of revisions you ask it to
display.  "bzr log", by contrast, is very fast (unless you go fancy
about how you select revisions, e.g. with "-r annotate:").  Guess what
I prefer first and foremost.

You consistently dismiss complaints in this area for reasons I cannot
understand.  Just because you don't need these tools does not yet mean
they aren't important for others.  I need them a lot while hacking the
display engine, because there's no one here who can help me understand
why a particular piece of code was written; by digging into the
history and finding out who committed it and when, I can most of the
time find the answers and DTRT.  But these complications are a huge
time drain for me.  Some of them are probably water under the bridge,
because of the way the CVS repository was converted to Bazaar (I guess
the limited testing done back then was not thorough enough), but
others can be avoided.

> The same kind of problems will show up with many other merges.
> The problem is not in the way those branches were handled or how the
> merge was done: the problem is that the request you use will not tell
> you quite what you're looking for (although it may occasionally do).

I don't agree.  In general, all the possible ways of asking something
should give you the same answer, otherwise you cannot really trust the
tool.  The discrepancy here happens because bzrmerge.el plays unholy
games with the metadata as opposed to the sources.  If we need to do
this, let's do it on the branch, as others suggested, not on the
trunk.  Alternatively, we could apply to the trunk changes from the
branch as simple diffs, with Patch.  I don't see how any of these two
alternatives are worse or harder than what we currently have.