Merging emacs-23 into trunk

Merging emacs-23 into trunk

[Stefan Monnier]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

FWIW, here's the code I've used to merge the emacs-23 branch into the
trunk.  It presumes that the commits I don't want to include have the
keyword "backport" or "merge" in it, so please make sure you include
such keywords in your "not to be merged" commits in the future.

It's pretty rough, and is scaringly slow (to some extent because of
bzr's braindead lack of support for merging into a tree that's not
clean).  But that merge seemed like a good opportunity, since it had
many backports and a naive merge generated tons of conflicts (a large
part of them due to "bump version").

BTW, thanks Chong for committing the "bump version" separately from any
real change, so I could just skip that patch rather than try and come up
with some clever way to recognize and auto-resolve the
resulting conflicts.


        Stefan

[-- Attachment #2: bzrmerge.el --]
[-- Type: application/emacs-lisp, Size: 13220 bytes --]

Re: Merging emacs-23 into trunk

[Glenn Morris]

Can you make it just skip merging configure altogether?
It's pointless to merge this generated file between branches, and it
creates merge diffs that are largely noise (eg most recent merge of
emacs23 to trunk).

Re: Merging emacs-23 into trunk

[Stephen J. Turnbull]

Glenn Morris writes:

 > Can you make it just skip merging configure altogether?

Not really.  That's inherent in the philosophy of atomic commits and
DAG-based merging.

A very dedicated maintainer with nothing better to do might be able to
make it appear like it isn't being merged by maintaining a separate
"no-configure" branch in which configure has been "bzr rm'd", then
merging Branch-A --> no-configure --> Branch-B.  I suspect that the
Branch-A --> no-configure merge will throw a remove/modify conflict
every time, but even if so this should be easy to automate with a
"bzr replay-recorded-resolution" command (a la git's "rerere" command,
if you know about that).  If there isn't one already, the Bazaar team
might be willing to cons one up.  Similar considerations would apply
on the no-configure --> Branch-B side.

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 10 Nov 2010 14:44:49 +0900
> Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org
> 
> Glenn Morris writes:
> 
>  > Can you make it just skip merging configure altogether?
> 
> Not really.  That's inherent in the philosophy of atomic commits and
> DAG-based merging.

I don't follow.  Do you have in mind a revision where configure was
committed together with other files?  If so, I understand.  But if it
was committed alone, what is the issue with atomic commits?

Re: Merging emacs-23 into trunk

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Wed, 10 Nov 2010 14:44:49 +0900
 > > Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, emacs-devel@gnu.org
 > > 
 > > Glenn Morris writes:
 > > 
 > >  > Can you make it just skip merging configure altogether?
 > > 
 > > Not really.  That's inherent in the philosophy of atomic commits and
 > > DAG-based merging.
 > 
 > I don't follow.  Do you have in mind a revision where configure was
 > committed together with other files?  If so, I understand.  But if it
 > was committed alone, what is the issue with atomic commits?

The words "philosophy" and "and" in my statement are crucial.  Of
course we've learned how to split an atom.  But then it's not an atom
any more.  Similarly, if you are going to commit changes to a
generated file, then it should be committed with the source changes
that generate them.

The DAG-based merging helps to enforce this because there's no way
that the VCS can determine that these changes are related via
syntactic analysis, and humans won't always get it right.  So DAG-
based merging takes branch history as the proxy for relatedness.
That's why workflows are so important.  If you want a "better" notion
of relatedness, use Darcs, which is designed to be more or less
workflow-free (but in practice doesn't achieve that yet).

The fact that Bazaar doesn't handle the situation very well is quite
apart from the design philosophy.

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: monnier@IRO.UMontreal.CA,
>     emacs-devel@gnu.org
> Date: Thu, 11 Nov 2010 11:28:39 +0900
> 
>  > >  > Can you make it just skip merging configure altogether?
>  > > 
>  > > Not really.  That's inherent in the philosophy of atomic commits and
>  > > DAG-based merging.
>  > 
>  > I don't follow.  Do you have in mind a revision where configure was
>  > committed together with other files?  If so, I understand.  But if it
>  > was committed alone, what is the issue with atomic commits?
> 
> The words "philosophy" and "and" in my statement are crucial.  Of
> course we've learned how to split an atom.  But then it's not an atom
> any more.  Similarly, if you are going to commit changes to a
> generated file, then it should be committed with the source changes
> that generate them.

If committing configure alone is all we need to avoid the problem, we
could decide to do that, philosophical and atom-splitting issues
notwithstanding.

Alternatively, "bzr revert configure" before committing the merges
should also do.

Re: Merging emacs-23 into trunk

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > If committing configure alone is all we need to avoid the problem, we
 > could decide to do that, philosophical and atom-splitting issues
 > notwithstanding.

No, I'm saying that the design of bzr doesn't permit that.

 > Alternatively, "bzr revert configure" before committing the merges
 > should also do.

As long as the Makefile knows to update configure, you're OK until
somebody with a different version of autoconf reports a bug.  Or
somebody with *no* autoconf decides to build, and gets stopped before
they get started even though they've got a perfectly good configure.

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: monnier@IRO.UMontreal.CA,
>     emacs-devel@gnu.org
> Date: Thu, 11 Nov 2010 17:39:05 +0900
> 
> Eli Zaretskii writes:
> 
>  > If committing configure alone is all we need to avoid the problem, we
>  > could decide to do that, philosophical and atom-splitting issues
>  > notwithstanding.
> 
> No, I'm saying that the design of bzr doesn't permit that.

??? Which part of design of bzr won't permit me doing the following?

  bzr ci configure.in ChangeLog
  bzr ci configure

> As long as the Makefile knows to update configure, you're OK until
> somebody with a different version of autoconf reports a bug.  Or
> somebody with *no* autoconf decides to build, and gets stopped before
> they get started even though they've got a perfectly good configure.

The issue of whether to have configure in the repository is a separate
one.  If the decision is not to track it, then, of course, all of the
above is not relevant.

Re: Merging emacs-23 into trunk

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > ??? Which part of design of bzr won't permit me doing the
 > following?

Eli, I have no idea how you could possibly think that's an appropriate
question at this point in the thread (and the same goes for several of
your following comments), so I'm going to quit while I'm ahead.

However, in considering how to reply, I did come up with one
suggestion possibly worthy of consideration.

 > The issue of whether to have configure in the repository is a separate
 > one.  If the decision is not to track it, then, of course, all of the
 > above is not relevant.

Obviously, configure *is* in the repo.  Then you either do something
to prevent the problems I described, or sooner or later they arise.
The obvious thing to do is to run autoconf, then commit configure
along with configure.in.

To keep Glenn happy, maybe the Bazaar guys can come up with a plugin
or a patch that allows you to configure files that should never be
diffed unless you ask for it (like binaries, you just get a stanza in
the diff that says the files differ but the diff itself is omitted
because the file appears in .diffignore or diff.ignore= in
.bzr/config).  That likely won't be too hard, because they have to do
something more complex to avoid spewing binary garbage, anyway.  So
there is some place where bzr is going, "oh, let's not display the
diff of this file" and suppressing either the diff operation itself or
the output.  Quite likely it's a couple of lines to change to add this
feature.

Re: Merging emacs-23 into trunk

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> Can you make it just skip merging configure altogether?

It should be regenerated whenever its sources changed (as long as we
keep it versioned).

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: Merging emacs-23 into trunk

[Stefan Monnier]

> Can you make it just skip merging configure altogether?

It "resolves" the conflict automatically by undoing the change.  But you
could easily add "configure" to the regexp of "commit message words that
indicate you might want to skip this commit".  It didn't seem worth the
trouble since I'd expect "configure" to often be committed together with
the corresponding change to configure.in.

> It's pointless to merge this generated file between branches, and it
> creates merge diffs that are largely noise (eg most recent merge of
> emacs23 to trunk).

AFAIK the merge I just committed should not have changed ./configure.


        Stefan

Re: Merging emacs-23 into trunk

[Glenn Morris]

Stefan Monnier wrote:

> AFAIK the merge I just committed should not have changed ./configure.

Well, just take a look at the diff:

http://lists.gnu.org/archive/html/emacs-diffs/2010-11/msg00141.html

By eye, it's about 75% configure.

Re: Merging emacs-23 into trunk

[Glenn Morris]

PS I don't recall seeing a compelling reason as to why configure needs
to be in the repository at all, so I still suggest just ditching it.

(src/config.in is needed by feeble platforms that can't generate it
themselves, but AFAIK this does not apply to configure.)

Re: Merging emacs-23 into trunk

[Chad Brown]

On Nov 10, 2010, at 12:42 PM, Glenn Morris wrote:

> PS I don't recall seeing a compelling reason as to why configure needs
> to be in the repository at all, so I still suggest just ditching it.

In the past, it has been pretty annoying to deal with version skew in autoconf, especially as different gnu packages required different versions (typically a `new/old' split).  I've no idea if this is a practical concern today; I do notice that version skew comes up now and then.

I hope that helps,
*Chad

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 10 Nov 2010 15:42:46 -0500
> Cc: emacs-devel@gnu.org
> 
> 
> PS I don't recall seeing a compelling reason as to why configure needs
> to be in the repository at all

The reason is that if we don't keep it in the repository, everyone
should have Autoconf installed.  Whether this is "compelling", I don't
know.

> (src/config.in is needed by feeble platforms that can't generate it
> themselves, but AFAIK this does not apply to configure.)

True.

Re: Merging emacs-23 into trunk

[Kenichi Handa]

In article <834obofqyk.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > PS I don't recall seeing a compelling reason as to why configure needs
> > to be in the repository at all

> The reason is that if we don't keep it in the repository, everyone
> should have Autoconf installed.  Whether this is "compelling", I don't
> know.

We can include configure in tarball.  For those who get the
source from bzr, asking them to install autoconf is, I
think, no big deal.

---
Kenichi Handa
handa@m17n.org

Re: Merging emacs-23 into trunk

[Glenn Morris]

Kenichi Handa wrote:

> We can include configure in tarball. For those who get the source
> from bzr, asking them to install autoconf is, I think, no big deal.

Absolutely. I think it is entirely reasonable to say "building Emacs
from bzr on a POSIX platform requires autoconf".

As a random data point, GNU make apparently did this years ago:

http://lists.gnu.org/archive/html/bug-make/2004-02/msg00040.html

Re: Merging emacs-23 into trunk

[Lennart Borgman]

On Thu, Nov 11, 2010 at 8:55 PM, Glenn Morris <rgm@gnu.org> wrote:
> Kenichi Handa wrote:
>
>> We can include configure in tarball. For those who get the source
>> from bzr, asking them to install autoconf is, I think, no big deal.
>
> Absolutely. I think it is entirely reasonable to say "building Emacs
> from bzr on a POSIX platform requires autoconf".


You are not building in the POSIX environment on w32.


> As a random data point, GNU make apparently did this years ago:
>
> http://lists.gnu.org/archive/html/bug-make/2004-02/msg00040.html
>
>

Re: Merging emacs-23 into trunk

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

>> Absolutely. I think it is entirely reasonable to say "building Emacs
>> from bzr on a POSIX platform requires autoconf".
>
> You are not building in the POSIX environment on w32.

Right. W32 has its own build system that does not rely on autoconf, so
W32 is irrelevant on this discussion.

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 11 Nov 2010 21:01:15 +0100
> Cc: Kenichi Handa <handa@m17n.org>, Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca, 
> 	emacs-devel@gnu.org
> 
> > I think it is entirely reasonable to say "building Emacs
> > from bzr on a POSIX platform requires autoconf".
> 
> 
> You are not building in the POSIX environment on w32.

A w32 build does not need nor care about the configure script.

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Tue, 09 Nov 2010 16:30:10 -0500
> 
> It's [...] scaringly slow (to some extent because of
> bzr's braindead lack of support for merging into a tree that's not
> clean).

I wanted to suggest "merge --force", but I see that you already tried
that:

>             ;; Stupidly, "bzr merge --force -r A..B" dos not maintain the
>             ;; metadata properly except when the checkout is clean.

Do you mean that "bzr merge --force" merges the text, but not the
history?  If not, what exactly is the problem?

Re: Merging emacs-23 into trunk

[Stefan Monnier]

>> It's [...] scaringly slow (to some extent because of bzr's braindead
>> lack of support for merging into a tree that's not clean).

> I wanted to suggest "merge --force", but I see that you already tried
> that:

>> ;; Stupidly, "bzr merge --force -r A..B" dos not maintain the
>> ;; metadata properly except when the checkout is clean.
> Do you mean that "bzr merge --force" merges the text, but not the
> history?

Yes: it does merge the history but only in the case where the local tree
has no pending merges (in which case bzrmerge can just use "merge -r B")

I.e. the result of doing

    bzr merge -r B
    
is never the same as doing

    bzr merge -r A
    bzr merge --force -r A..B

While I do expect the two to behave differently w.r.t conflicts (or in
the case where A>B, say), I think the fact that the second does not
register the revisions from A to B in the "pending merges" data seems
like a bug to me.

And the fact that

    bzr merge -r A
    bzr merge --force -r B

applies the A changes twice is another bug.  Basically, "bzr merge"
completely ignores pending merges.  As does "bzr diff" (and probably
most/all other commands) BTW.


        Stefan

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 10 Nov 2010 10:46:02 -0500
> 
>     bzr merge -r A
>     bzr merge --force -r A..B
> 
> While I do expect the two to behave differently w.r.t conflicts (or in
> the case where A>B, say), I think the fact that the second does not
> register the revisions from A to B in the "pending merges" data seems
> like a bug to me.

You are cherry-picking here; cherry-picking is explicitly not tracked
in the history DAG.  Why is that a problem, in the context of this
discussion (merging from a release branch to the trunk)?

> And the fact that
> 
>     bzr merge -r A
>     bzr merge --force -r B
> 
> applies the A changes twice is another bug.

I think this is again because cherry-picking is not tracked, so bzr
doesn't "know" A is already there.  In a nutshell, when you
cherry-pick, you need to do your own bookkeeping.

Re: Merging emacs-23 into trunk

[Stefan Monnier]

>> bzr merge -r A
>> bzr merge --force -r A..B
>> 
>> While I do expect the two to behave differently w.r.t conflicts (or in
>> the case where A>B, say), I think the fact that the second does not
>> register the revisions from A to B in the "pending merges" data seems
>> like a bug to me.

> You are cherry-picking here; cherry-picking is explicitly not tracked
> in the history DAG.

Actually, I'm not cherry-picking: Since all changes until A have been
merged, merging A..B will end up with all changes until B: I'm not
picking some changes and avoiding others.
And indeed

  bzr merge -r A..B

will correctly track the history in the case where A has already been
merged and committed.

> Why is that a problem, in the context of this discussion (merging from
> a release branch to the trunk)?

Because, in order to cherry-pick, I merge the various parts of the
emacs-23 branch differently, so I need to issue various "bzr merge"
commands to merge the branch bit by bit.

I could work around this limitation by working on a separate temporary
branch (where I can commit after each "bzr merge") and then merge that
temporary branch into trunk.

>> And the fact that
>> bzr merge -r A
>> bzr merge --force -r B
>> applies the A changes twice is another bug.

> I think this is again because cherry-picking is not tracked, so bzr
> doesn't "know" A is already there.  In a nutshell, when you
> cherry-pick, you need to do your own bookkeeping.

Where do you see cherry-picking in the above commands: the -r argument
always specifies just a revision on the branch, not a "A..B".


        Stefan

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 10 Nov 2010 14:03:05 -0500
> 
> > You are cherry-picking here; cherry-picking is explicitly not tracked
> > in the history DAG.
> 
> Actually, I'm not cherry-picking

I think you are.  From the docs of "bzr merge":

  When merging a branch, by default the tip will be merged.  To pick a
  different revision, pass --revision.  If you specify two values, the
  first will be used as BASE and the second one as OTHER.  Merging
  individual revisions, or a subset of available revisions, like this is
  commonly referred to as “cherrypicking”.

> Since all changes until A have been merged, merging A..B will end up
> with all changes until B: I'm not picking some changes and avoiding
> others.  And indeed
> 
>   bzr merge -r A..B
> 
> will correctly track the history in the case where A has already been
> merged and committed.

Maybe it's some exception, for when A is the BASE revision; the rule
(AFAIU) is what I quote above.  When I use "merge -r", I don't expect
bzr to track the merge in the branch history.

Perhaps you need to ask about this on the Bazaar list.

> > Why is that a problem, in the context of this discussion (merging from
> > a release branch to the trunk)?
> 
> Because, in order to cherry-pick, I merge the various parts of the
> emacs-23 branch differently, so I need to issue various "bzr merge"
> commands to merge the branch bit by bit.

I still don't understand the problem.  Maybe it will become more clear
if you could show what you'd like to do, as opposed to what you need
to do, due to these limitations.

> >> And the fact that
> >> bzr merge -r A
> >> bzr merge --force -r B
> >> applies the A changes twice is another bug.
> 
> > I think this is again because cherry-picking is not tracked, so bzr
> > doesn't "know" A is already there.  In a nutshell, when you
> > cherry-pick, you need to do your own bookkeeping.
> 
> Where do you see cherry-picking in the above commands: the -r argument
> always specifies just a revision on the branch, not a "A..B".

AFAIU, "-r A" is just a shorthand for "-r A..-1".  If A is an
arbitrary revision on the branch being merged, you just cherry-pick
all the revisions from A to the branch tip.

Re: Merging emacs-23 into trunk

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> AFAIU, "-r A" is just a shorthand for "-r A..-1".  If A is an
> arbitrary revision on the branch being merged, you just cherry-pick
> all the revisions from A to the branch tip.

From "bzr help merge":

> To merge changes up to and including revision 82 from bzr.dev:
>
>        bzr merge -r 82 ../bzr.dev

So it doesn't mean "from A", but "up to and including A".

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 10 Nov 2010 20:36:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> [snip]
> 
> > AFAIU, "-r A" is just a shorthand for "-r A..-1".  If A is an
> > arbitrary revision on the branch being merged, you just cherry-pick
> > all the revisions from A to the branch tip.
> 
> From "bzr help merge":
> 
> > To merge changes up to and including revision 82 from bzr.dev:
> >
> >        bzr merge -r 82 ../bzr.dev
> 
> So it doesn't mean "from A", but "up to and including A".

Okay, but it's still cherry-picking of a certain range of revisions,
right?

Re: Merging emacs-23 into trunk

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > AFAIU, "-r A" is just a shorthand for "-r A..-1".  If A is an
>> > arbitrary revision on the branch being merged, you just cherry-pick
>> > all the revisions from A to the branch tip.
>> 
>> From "bzr help merge":
>> 
>> > To merge changes up to and including revision 82 from bzr.dev:
>> >
>> >        bzr merge -r 82 ../bzr.dev
>> 
>> So it doesn't mean "from A", but "up to and including A".
>
> Okay, but it's still cherry-picking of a certain range of revisions,
> right?

Nope. It searches the common ancestor and merges from there to A. That's
a real VC history merge, i.e. one that preserves commit identity.

The last phrase is crucial. If you cherry-picked some commit on that
range, bzr does not remember it and it will be merged again, this time
preserving its revision id.

(I don't know what happens if A was already merged (not cherry-picked))

Re: Merging emacs-23 into trunk

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Actually, I'm not cherry-picking
 > 
 > I think you are.  From the docs of "bzr merge":

You of all people whould know better than to trust the Bazaar docs!

There are two different, though closely related, definitions, of
"cherrypicking" in practice.

Definition 1, "merging individual revisions, or a subset of available
revisions", is the one used by the Bazaar documents and the Bazaar
developers.

Definition 2, which is the one Stefan is implicitly using, is "merging
individual revisions, or a subset of available revisions, *forcing the
VCS to forget* associations between changes and revisions."  (My
wording is a bit awkward because this subtlety is almost never made
explicit; this is the first time I've tried.)

In the DAG-oriented VCSes (git, Mercurial, Bazaar), there is no
practical difference because once you ask for an out-of-order patch
application the DAG no longer applies simplistically; in particular,
you can't compute the ancestor for a three-way merge.  By design they
forget.  ("git filter-branch" and "git rebase --interactive" are hacks
allowing you to provide the necessary information out-of-DAG.)

GNU Arch (and Darcs) know which changes have been applied to the tree;
there is no presumption that they are applied in history-determined
subsets.  (The difference between Arch and Darcs is that Arch required
the user to try applying and then resolve conflicts at the changeset
level, one after another; Darcs is smart enough to compute where
conflicts will occur, and it then rearranges hunk order to maximize
automatic application before asking the user to resolve conflicts.)

Stefan, who is familiar with both GNU Arch and Darcs, I believe,
correctly perceives Bazaar behavior as a huge regression vs. Arch in
this respect.

Re: Merging emacs-23 into trunk

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>     emacs-devel@gnu.org
> Date: Thu, 11 Nov 2010 11:52:38 +0900
> 
> Eli Zaretskii writes:
> 
>  > > Actually, I'm not cherry-picking
>  > 
>  > I think you are.  From the docs of "bzr merge":
> 
> You of all people whould know better than to trust the Bazaar docs!

You of all people should know that in this case Bazaar docs say what
the developers meant and faithfully describe what bzr does.

(My problem with Bazaar docs is that it doesn't say enough.  When it
does describe something, the description is usually correct, although
it could be misplaced and hard to find.)

> There are two different, though closely related, definitions, of
> "cherrypicking" in practice.

Since this is about Bazaar, I was talking about this meaning, and this
meaning alone.

> Stefan, who is familiar with both GNU Arch and Darcs, I believe,
> correctly perceives Bazaar behavior as a huge regression vs. Arch in
> this respect.

The issue is not whether this bzr behavior is useful.  The issue is
whether it is by design and documentation.  Stefan thinks he was not
cherrypicking, so he believes that the parts of the docs I cited are
not applicable to what he did.

Re: Merging emacs-23 into trunk

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> You are cherry-picking here; cherry-picking is explicitly not tracked
>> in the history DAG.
>
> Actually, I'm not cherry-picking: Since all changes until A have been
> merged, merging A..B will end up with all changes until B: I'm not
> picking some changes and avoiding others.
> And indeed
>
>   bzr merge -r A..B
>
> will correctly track the history in the case where A has already been
> merged and committed.

No. It will keep the order of the commits, but that's is all it does as
far as the VC history is concerned.

In general, merge -r A..C is the same as the sequence

merge -c A
merge -c B
merge -c C

When you cherry-pick a commit (either individually or as a part of a
range) that commit loses its identity and appears as a new one on the
target branch. bzr has no way of knowing that a commit you cherry-picked
already is on the target branch, and hence it will not complain if you
merge it again.

`bzr qlog' on trunk just after cherry-picking the changes from emacs-23
will be illustrative.

[snip]

Re: Merging emacs-23 into trunk

[Stefan Monnier]

>>> You are cherry-picking here; cherry-picking is explicitly not tracked
>>> in the history DAG.
>> Actually, I'm not cherry-picking: Since all changes until A have been
>> merged, merging A..B will end up with all changes until B: I'm not
>> picking some changes and avoiding others.
>> And indeed
>> bzr merge -r A..B
>> will correctly track the history in the case where A has already been
>> merged and committed.

> No. It will keep the order of the commits, but that's is all it does as
> far as the VC history is concerned.

I have no idea what you mean by the above, but I have tried and tested

  bzr merge -r A..B
  
and in all my tests, in the case where A has already been merged into
the current tree, it behaves exactly like

  bzr merge -r B

with respect to history-tracking.


        Stefan

Re: Merging emacs-23 into trunk

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> You are cherry-picking here; cherry-picking is explicitly not tracked
>>>> in the history DAG.
>>> Actually, I'm not cherry-picking: Since all changes until A have been
>>> merged, merging A..B will end up with all changes until B: I'm not
>>> picking some changes and avoiding others.
>>> And indeed
>>> bzr merge -r A..B
>>> will correctly track the history in the case where A has already been
>>> merged and committed.
>
>> No. It will keep the order of the commits, but that's is all it does as
>> far as the VC history is concerned.
>
> I have no idea what you mean by the above, but I have tried and tested
>
>   bzr merge -r A..B
>   
> and in all my tests, in the case where A has already been merged into
> the current tree, it behaves exactly like
>
>   bzr merge -r B
>
> with respect to history-tracking.

Yes, when A (or its parent) already is on the target branch with the
same revision-id as it has on the source branch.

But if you cherry-picked A (instead of merging it) you will end with two
instances of the commit that corresponds to A in the VC history: one
corresponds to the cherry-pick and another to the merge. (It is
unfortunate that `bzr merge' is used for merging history and for
cherry-picking).

Another case is when the parent of A is not on the target branch (with
the same revision-id it has on the source branch.) Then you are
cherry-picking a series of commits.

Re: Merging emacs-23 into trunk

[Óscar Fuentes]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Yes, when A (or its parent) already is on the target branch with the
>> same revision-id as it has on the source branch.
>
> Which is exactly the situation I was talking about:
>
>     And indeed
>        bzr merge -r A..B
>     will correctly track the history in the case where A has already been
>     merged and committed.

"merge -r A..B" usually means a cherry-pick, because for the case when
it is a merge there is no reason to specify A (the tool figures it out
automatically) but it seems that you missed the syntax "merge -r B"

Re: Merging emacs-23 into trunk

[Stefan Monnier]

>>> Yes, when A (or its parent) already is on the target branch with the
>>> same revision-id as it has on the source branch.
>> 
>> Which is exactly the situation I was talking about:
>> 
>> And indeed
>> bzr merge -r A..B
>> will correctly track the history in the case where A has already been
>> merged and committed.

> "merge -r A..B" usually means a cherry-pick,

In the context of "where A has already been merged and committed", it's
not "usually" a cherry-pick: it's never a cherry-pick.

> because for the case when
> it is a merge there is no reason to specify A (the tool figures it out
> automatically) but it seems that you missed the syntax "merge -r B"

No, I didn't miss this syntax (as you can tell by looking at the
code I sent ;-).


        Stefan