Latest merge from the emacs-23 branch

Latest merge from the emacs-23 branch

[Eli Zaretskii]

The latest merge, which created revision 102642 on the trunk, shows a
lot of revisions from the branch as merged (to see them, try something
like "bzr log --line -c102642 -n0"), but at least some of them are not
actually included in the merge.  Here are a few examples:

 99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs...
 99634.2.664: Glenn Morris 2010-12-11 [Backport from trunk]: * make-dist: E...
 99634.2.658: Eli Zaretskii 2010-12-09 Fix bug #1077 with popping new frame...

These revisions indeed should not have been merged to the trunk, but
why do they show in Bazaar's merge log?  That will certainly
complicate future forensics, I think.

Re: Latest merge from the emacs-23 branch

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> The latest merge, which created revision 102642 on the trunk, shows a
> lot of revisions from the branch as merged (to see them, try something
> like "bzr log --line -c102642 -n0"), but at least some of them are not
> actually included in the merge.  Here are a few examples:
>
>  99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs...
>  99634.2.664: Glenn Morris 2010-12-11 [Backport from trunk]: * make-dist: E...
>  99634.2.658: Eli Zaretskii 2010-12-09 Fix bug #1077 with popping new frame...
>
> These revisions indeed should not have been merged to the trunk, but
> why do they show in Bazaar's merge log?

That's the difference between merging and cherry picking.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Latest merge from the emacs-23 branch

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 17 Dec 2010 19:19:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The latest merge, which created revision 102642 on the trunk, shows a
> > lot of revisions from the branch as merged (to see them, try something
> > like "bzr log --line -c102642 -n0"), but at least some of them are not
> > actually included in the merge.  Here are a few examples:
> >
> >  99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs...
> >  99634.2.664: Glenn Morris 2010-12-11 [Backport from trunk]: * make-dist: E...
> >  99634.2.658: Eli Zaretskii 2010-12-09 Fix bug #1077 with popping new frame...
> >
> > These revisions indeed should not have been merged to the trunk, but
> > why do they show in Bazaar's merge log?
> 
> That's the difference between merging and cherry picking.

Cherry-picking is not recorded in the history, so it cannot explain
the extra records.  Merging and _then_reverse_cherry-picking_ can, but
I'd like Stefan to respond, because only he knows what he did.

More importantly, I'd like to know if this was an accident or
something that can and will be improved, or this is how merges between
branches will look like from now on.

Re: Latest merge from the emacs-23 branch

[Stefan Monnier]

> The latest merge, which created revision 102642 on the trunk, shows a
> lot of revisions from the branch as merged (to see them, try something
> like "bzr log --line -c102642 -n0"), but at least some of them are not
> actually included in the merge.  Here are a few examples:

>  99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs...
>  99634.2.664: Glenn Morris 2010-12-11 [Backport from trunk]: * make-dist: E...
>  99634.2.658: Eli Zaretskii 2010-12-09 Fix bug #1077 with popping new frame...

> These revisions indeed should not have been merged to the trunk, but
> why do they show in Bazaar's merge log?  That will certainly
> complicate future forensics, I think.

Cherrypicking is unworkable since it means doing all the
history-tracking by hand.  So the "merge from emacs-23" is *really*
a merge.  I'm not sure what you mean by "some of them are not
actually included in the merge", tho.  AFAIK they are included in the
sense that the corresponding change is now present on the trunk.


        Stefan

Re: Latest merge from the emacs-23 branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 17 Dec 2010 17:03:01 -0500
> 
> Cherrypicking is unworkable since it means doing all the
> history-tracking by hand.

What do you mean by "history-tracking", and why do we need to do it by
hand?

> I'm not sure what you mean by "some of them are not actually
> included in the merge", tho.  AFAIK they are included in the sense
> that the corresponding change is now present on the trunk.

No, there actually seem to be 2 different revisions on the trunk now that
appear to solve the same issue in two different ways.  For example, this
"merge":

 99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs

is also present here:

 102637: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs

and this "merge":

 99634.2.658: Eli Zaretskii 2010-12-09 Fix bug #1077 with popping new frames

is also here:

 102619: Eli Zaretskii 2010-12-09 Fix bug #1077 with popping new frames

E.g., try these two commands:

  bzr diff -c99634.2.670
  bzr diff -c102637

and you will see 2 different changes that seem to fix the same bug in
two slightly different ways.

Moreover, "bzr log -c99634.2.658" displays this:

  revno: 99634.2.658
  fixes bug(s): http://debbugs.gnu.org/1077
  committer: Eli Zaretskii <eliz@gnu.org>
  branch nick: emacs-23
  timestamp: Thu 2010-12-09 18:53:17 +0000
  message:
    Fix bug #1077 with popping new frames from a minibuffer-only frame.

    Do NOT merge with trunk!
    ^^^^^^^^^^^^^^^^^^^^^^^^

Reading such log messages will result in a lot of confusion, I'm
afraid.

Re: Latest merge from the emacs-23 branch

[Stefan Monnier]

>> Cherrypicking is unworkable since it means doing all the
>> history-tracking by hand.
> What do you mean by "history-tracking", and why do we need to do it by
> hand?

By history tracking I mean keeping track of what has been merged where
and when.  E.g. CVS did not do it and this is one of the main reasons
why I've pushed to change VCS.  When we want to add the content of one
branch to another, we need to know that history in order to know which
part of the branch still needs to be added.  As long as we do "whole
branch merges", Bazaar keeps track of it for us.  If we start doing it
piecewise, Bazaar doesn't know how to do it for us, so we'd have to do
it by hand.  We used to do it by hand with CVS, but we did it for "whole
branch merges", which is the easy case (so easy that even Bazaar can do
it for us)., doing it on a revision-by-revision basis is a lot
more troublesome.

>> I'm not sure what you mean by "some of them are not actually
>> included in the merge", tho.  AFAIK they are included in the sense
>> that the corresponding change is now present on the trunk.

> No, there actually seem to be 2 different revisions on the trunk now that
> appear to solve the same issue in two different ways.  For example, this
> "merge":

>  99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs

> is also present here:

>  102637: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs

Yup.  This is a non-issue.

> Reading such log messages will result in a lot of confusion, I'm
> afraid.

Time will tell if your fear is justified.


        Stefan

Re: Latest merge from the emacs-23 branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sat, 18 Dec 2010 10:58:14 -0500
> 
> >> Cherrypicking is unworkable since it means doing all the
> >> history-tracking by hand.
> > What do you mean by "history-tracking", and why do we need to do it by
> > hand?
> 
> By history tracking I mean keeping track of what has been merged where
> and when.

Okay, then how about including with the merge commit message the list
of revisions you backed out after merging?  This list cannot be too
long (otherwise merging doesn't make sense).  Until now we only had a
laconic "merge from emacs-23" as the log message.

> > No, there actually seem to be 2 different revisions on the trunk now that
> > appear to solve the same issue in two different ways.  For example, this
> > "merge":
> 
> >  99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs
> 
> > is also present here:
> 
> >  102637: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs
> 
> Yup.  This is a non-issue.

It will be a non-issue if there's a way to know that 99634.2.670 was
reverse cherry-picked after merging.  Otherwise, how can I distinguish
between this case and the case of erroneously merging from the branch
(which happened in the past)?

Re: Latest merge from the emacs-23 branch

[Stefan Monnier]

> Okay, then how about including with the merge commit message the list
> of revisions you backed out after merging?  This list cannot be too
> long (otherwise merging doesn't make sense).

Actually, the list can be any length and the merge would still make
sense, because the merge of changes we actually don't want is performed
to make future merges easier (and to keep track of the fact that we
already did what we had to do with these changes (i.e. "not merge it")).

In practice the list tends to be reasonably short (since it only
includes things like backports plus a few changes that are already
overridden on the trunk, like changing the release number).  So we could
probably include it, tho it's more work.  Currently, the output that my
script gets doesn't mention revision ids, only revision numbers and log
messages, so maybe we could just include the first line of commit
messages instead of revision ids.

>> > No, there actually seem to be 2 different revisions on the trunk now that
>> > appear to solve the same issue in two different ways.  For example, this
>> > "merge":
>> >  99634.2.670: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs
>> > is also present here:
>> >  102637: Eli Zaretskii 2010-12-11 Fix bug #7398 with truncated glyphs
>> Yup.  This is a non-issue.
> It will be a non-issue if there's a way to know that 99634.2.670 was
> reverse cherry-picked after merging.  Otherwise, how can I distinguish
> between this case and the case of erroneously merging from the branch
> (which happened in the past)?

By looking at the code.  Even with more metadata, only the code can tell
you what was actually changed since the metadata can only tell you what
bzr commands were used (and even that only to a limited extent since my
script uses various ways to cheat around bzr's limitations), but not how
conflicts were resolved manually or what extra manual changes
were performed.


        Stefan

Re: Latest merge from the emacs-23 branch

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sun, 19 Dec 2010 08:47:18 -0500
> 
> In practice the list tends to be reasonably short (since it only
> includes things like backports plus a few changes that are already
> overridden on the trunk, like changing the release number).  So we could
> probably include it, tho it's more work.  Currently, the output that my
> script gets doesn't mention revision ids, only revision numbers and log
> messages, so maybe we could just include the first line of commit
> messages instead of revision ids.

That'd be good, thanks.

> > how can I distinguish between this case and the case of
> > erroneously merging from the branch (which happened in the past)?
> 
> By looking at the code.

You mean, I need to give up using "bzr diff" (or the corresponding VC
commands), which AFAIK are based on the history metadata, and instead
use "bzr cat" on each one of two (or 3) revisions, then run Diff on
them?  That'd be a major inconvenience.

> Even with more metadata, only the code can tell
> you what was actually changed since the metadata can only tell you what
> bzr commands were used (and even that only to a limited extent since my
> script uses various ways to cheat around bzr's limitations), but not how
> conflicts were resolved manually or what extra manual changes
> were performed.

If we cheat Bazaar too much, we will eventually cheat ourselves,
because output of a "cheated" tool cannot be trusted.