* Latest merge from the emacs-23 branch
@ 2010-12-17 16:03 Eli Zaretskii
2010-12-17 18:19 ` Andreas Schwab
2010-12-17 22:03 ` Stefan Monnier
0 siblings, 2 replies; 9+ messages in thread
From: Eli Zaretskii @ 2010-12-17 16:03 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Latest merge from the emacs-23 branch
2010-12-17 16:03 Latest merge from the emacs-23 branch Eli Zaretskii
@ 2010-12-17 18:19 ` Andreas Schwab
2010-12-17 19:22 ` Eli Zaretskii
2010-12-17 22:03 ` Stefan Monnier
1 sibling, 1 reply; 9+ messages in thread
From: Andreas Schwab @ 2010-12-17 18:19 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Latest merge from the emacs-23 branch
2010-12-17 18:19 ` Andreas Schwab
@ 2010-12-17 19:22 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2010-12-17 19:22 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Latest merge from the emacs-23 branch
2010-12-17 16:03 Latest merge from the emacs-23 branch Eli Zaretskii
2010-12-17 18:19 ` Andreas Schwab
@ 2010-12-17 22:03 ` Stefan Monnier
2010-12-17 23:06 ` Eli Zaretskii
1 sibling, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2010-12-17 22:03 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Latest merge from the emacs-23 branch
2010-12-17 22:03 ` Stefan Monnier
@ 2010-12-17 23:06 ` Eli Zaretskii
2010-12-18 15:58 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2010-12-17 23:06 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Latest merge from the emacs-23 branch
2010-12-17 23:06 ` Eli Zaretskii
@ 2010-12-18 15:58 ` Stefan Monnier
2010-12-18 17:37 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2010-12-18 15:58 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Latest merge from the emacs-23 branch
2010-12-18 15:58 ` Stefan Monnier
@ 2010-12-18 17:37 ` Eli Zaretskii
2010-12-19 13:47 ` Stefan Monnier
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2010-12-18 17:37 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> 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)?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Latest merge from the emacs-23 branch
2010-12-18 17:37 ` Eli Zaretskii
@ 2010-12-19 13:47 ` Stefan Monnier
2010-12-19 15:10 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2010-12-19 13:47 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Latest merge from the emacs-23 branch
2010-12-19 13:47 ` Stefan Monnier
@ 2010-12-19 15:10 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2010-12-19 15:10 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-12-19 15:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-17 16:03 Latest merge from the emacs-23 branch Eli Zaretskii
2010-12-17 18:19 ` Andreas Schwab
2010-12-17 19:22 ` Eli Zaretskii
2010-12-17 22:03 ` Stefan Monnier
2010-12-17 23:06 ` Eli Zaretskii
2010-12-18 15:58 ` Stefan Monnier
2010-12-18 17:37 ` Eli Zaretskii
2010-12-19 13:47 ` Stefan Monnier
2010-12-19 15:10 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.