failure rebasing a merge

Bug #126743 reported by Jelmer Vernooij
2
Affects Status Importance Assigned to Milestone
bzr-rewrite
Fix Released
High
Jelmer Vernooij

Bug Description

as reported by dato on IRC:

$ b get -r 2540 bzr.dev B
$ cd B
$ echo hi >>NEWS
$ b ci -m foo
$ b merge -r 2552
$ b ci -m merge
$ b rebase

results in conflicts.

Revision history for this message
Jelmer Vernooij (jelmer) wrote : Re: [Bug 126743] failure rebasing a merge

  status triaged
  importance high

Jelmer Vernooij (jelmer)
Changed in bzr-rebase:
importance: Undecided → High
status: New → Triaged
Revision history for this message
John A Meinel (jameinel) wrote :

In discussing this with Jelmer on IRC, it seems that when rebase is trying to re-apply the merge, it is re-applying something that is already in the ancestry. For example:

A
|\
B C
|\|
D E
  |
  F

If you rebase "F" on top of "D", then you get something like:

A
|
B
|\
D |
| |
C'|
|/
E'
|
F'

And it is a little weird to merge B into a descendent of itself. So what you
should really get is:

A
|
B
|
D
|
C'
|
F'

On the other hand if you have:

A-.
|\ \
B C D
| |/
E F

And you rebase 'F' onto 'E', then you *should* get:

A
|\
B D
| |
E |
| |
C'|
|/
F'

So I think when rebase comes to a node which is a merge, it should check if all
merged revisions are already present. If so, then it should just skip that
node, and move to the next. Otherwise do the same cherry-pick merge, of the
changes against the primary parent, and mark the merged revision id.

Jelmer Vernooij (jelmer)
Changed in bzr-rebase:
assignee: nobody → jelmer
status: Triaged → Fix Committed
Revision history for this message
Jelmer Vernooij (jelmer) wrote :
Changed in bzr-rebase:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.