D8115: rebase: show bug when rebasing merge with obsoleted revs on both sides

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

D8115: rebase: show bug when rebasing merge with obsoleted revs on both sides

martinvonz (Martin von Zweigbergk)
durin42 created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  By inspection, the rebase should be fine: "just" omit 8 and 10 from
  the rebase. This is a simplified case of something we're seeing at
  Google.
 
  DO NOT ACCEPT: this is being shared to try and get help figuring out
  how to resolve the issue.

REPOSITORY
  rHG Mercurial

BRANCH
  default

REVISION DETAIL
  https://phab.mercurial-scm.org/D8115

AFFECTED FILES
  tests/test-rebase-obsolete.t

CHANGE DETAILS

diff --git a/tests/test-rebase-obsolete.t b/tests/test-rebase-obsolete.t
--- a/tests/test-rebase-obsolete.t
+++ b/tests/test-rebase-obsolete.t
@@ -2136,3 +2136,79 @@
   |/
   o  0: 1994f17a630e 'A' bookmarks:
   
+Rebase a merge where some of the ancestors on both sides of the merge
+have successors that have linearized.
+
+  $ echo alpha > alpha
+  $ hg ci -Am alpha alpha
+  created new head
+  $ echo beta > beta
+  $ hg ci -Am beta beta
+  $ hg co 5
+  0 files updated, 0 files merged, 2 files removed, 0 files unresolved
+  $ echo gamma > gamma
+  $ hg ci -Am gamma gamma
+  created new head
+  $ echo delta > delta
+  $ hg ci -Am delta delta
+  $ hg merge 9
+  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
+  (branch merge, don't forget to commit)
+  $ hg ci -m merge
+  $ hg co 7
+  2 files updated, 0 files merged, 4 files removed, 0 files unresolved
+  $ echo alphaprime > alpha
+  $ hg ci -Am alphaprime alpha
+  $ echo gammaprime > gamma
+  $ hg ci -Am gammaprime gamma
+  $ hg debugobsolete `hg log -r 8 -T'{node}'` `hg log -r 13 -T'{node}'`
+  1 new obsolescence markers
+  obsoleted 1 changesets
+  2 new orphan changesets
+  $ hg debugobsolete `hg log -r 10 -T'{node}'` `hg log -r 14 -T'{node}'`
+  1 new obsolescence markers
+  obsoleted 1 changesets
+  1 new orphan changesets
+  $ hg log -GT "{rev}: {node|short} '{desc}'"
+  @  14: c87966a2bac9 'gammaprime'
+  |
+  o  13: 6405e0193644 'alphaprime'
+  |
+  | *    12: 608f8c33b2dd 'merge'
+  | |\
+  | | *  11: 8415a35bb872 'delta'
+  | | |
+  | | x  10: 4219fc7517e7 'gamma'
+  | | |
+  | * |  9: 6cf04930d1a4 'beta'
+  | | |
+  | x |  8: a71f025d4776 'alpha'
+  | |/
+  o |  7: 9c86c650b686 'C'
+  | |
+  o |  6: 9b87b54e5fd8 'B'
+  |/
+  o  5: 39adf30bc1be 'conflict with d'
+  |
+  o  4: 9c1e55f411b6 'E'
+  |
+  | *  3: 67a385d4e6f2 'D'
+  | |
+  | x  2: 49cb3485fa0c 'C'
+  | |
+  | x  1: 6c81ed0049f8 'B'
+  |/
+  o  0: 1994f17a630e 'A'
+  
+  $ hg co 12
+  4 files updated, 0 files merged, 2 files removed, 0 files unresolved
+Sadness: the rebase doesn't work, because it's confused by the
+linearization that's taken place. :(
+  $ hg rebase -d 14
+  note: not rebasing 8:a71f025d4776 "alpha", already in destination as 13:6405e0193644 "alphaprime"
+  rebasing 9:6cf04930d1a4 "beta"
+  note: not rebasing 10:4219fc7517e7 "gamma", already in destination as 14:c87966a2bac9 "gammaprime" (tip)
+  rebasing 11:8415a35bb872 "delta"
+  rebasing 12:608f8c33b2dd "merge"
+  abort: rebasing 12:608f8c33b2dd will include unwanted changes from 8:a71f025d4776 or 10:4219fc7517e7
+  [255]



To: durin42, #hg-reviewers
Cc: mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

D8115: rebase: show bug when rebasing merge with obsoleted revs on both sides

martinvonz (Martin von Zweigbergk)
martinvonz added a comment.


  We already have tests for this (grepping for "unwanted changes" in `tests/` should be enough to find them).
 
  It's not easy to omit revisions 8 and 10 from the rebase. The key is to realize that rebase is done by repeated grafting of diffs and that the diffs are always between two commits. We can therefore rebase revisions 9 and 11 without a problem (we take the diff from revisions 8 and 10, respectively). But when rebasing the merge commit, which diff do we graft? If we use 9 as base (i.e. we try to graft the diff between 9 and 12), we'll get unwanted changes from commit 10. Conversely, if we use 11 as base, we'll get unwanted changes from commit 8.
 
  I have been thinking a bit about how to solve it by doing the rebase in smaller steps, but it's pretty complicated and maybe I should write it down in a plan page instead.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D8115/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D8115

To: durin42, #hg-reviewers
Cc: martinvonz, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Reply | Threaded
Open this post in threaded view
|

D8115: rebase: show bug when rebasing merge with obsoleted revs on both sides

martinvonz (Martin von Zweigbergk)
In reply to this post by martinvonz (Martin von Zweigbergk)
marmoute added a comment.


  In D8115#121345 <https://phab.mercurial-scm.org/D8115#121345>, @martinvonz wrote:
 
  > We already have tests for this (grepping for "unwanted changes" in `tests/` should be enough to find them).
  > It's not easy to omit revisions 8 and 10 from the rebase. The key is to realize that rebase is done by repeated grafting of diffs and that the diffs are always between two commits. We can therefore rebase revisions 9 and 11 without a problem (we take the diff from revisions 8 and 10, respectively). But when rebasing the merge commit, which diff do we graft? If we use 9 as base (i.e. we try to graft the diff between 9 and 12), we'll get unwanted changes from commit 10. Conversely, if we use 11 as base, we'll get unwanted changes from commit 8.
  > I have been thinking a bit about how to solve it by doing the rebase in smaller steps, but it's pretty complicated and maybe I should write it down in a plan page instead.
 
  looks like a legitimate need for 5 ways merge.
 
  @durin42 can we get this revision out of yadda? It is not ready to land and we won't have a solution soon™

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D8115/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D8115

To: durin42, #hg-reviewers
Cc: marmoute, martinvonz, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel