Differences between revisions 2 and 9 (spanning 7 versions)

Rebase with obsoleted changesets in rebaseset

$/!\$ This page is intended for developer

This page collects situations and discussion about rebase where the rebaseset contains obsoleted changesets.

Contents

Rebase with obsoleted changesets in rebaseset
1. Situations
2. Related issues

Situations

Successor is an ancestor of dest

  Z E # E: unstable
  | |
 D' D # D: replaced by D'
  | |
  B C
  |/
  A

rebase -s C -d Z can just skip D

  E'
  |
  C'
  |
  Z 
  | 
  ~

Successor is also in a rebase set

This is probably the most interesting one.

    E    # E: unstable
    |
  Z D D' # D: replaced by D'
  | |/
  B C
  |/
  A

Option 1 (rebase markers): rebase -s C -d Z creates new markers, avoid potential merge conflicts (in case the user knows there will be a conflict and wants to edit D"' before rebase E'). Like Option 5, plus creating new markers. The main concern is marker explosion.

    E'
    |
   D" D"' # D": replaced by D"'
    |/
    C'
   /
  Z
  |
  ~

Option 2: rebase -s C -d Z (with some flag?) skips precursors(rebaseset):: in rebaseset. In the example case, E remains at the old position. The user need to run another rebase -s E -d D"' to move E. There is no D" like Option 1 so the user cannot create divergence easily and conflict of rebasing E can be handled later. The downside is not intuitive - users may expect C to be "extinct" (i.e. not shown up in hg sl) after rebase -s C -d ....

    D"'
    |
    C'E # E: unstable
   / /
  Z D D' # D: replaced by D'; D': replaced by D"'
  | |/
  B C # C: replaced by C'
  |/
  A

Option 3: rebase -s C -d Z --evolve auto rebases E' to D"', does not create D", and does not create new markers. Like running "hg evolve" after Option 1. This is consistent with the --evolve flag below.

    E'
    |
    D"'
    |
    C'
   /
  Z
  |
  ~

Option 4 (current behavior, not ideal): rebase -s C -d Z aborts
Option 5 (current behavior with experimental.allowdivergence=1, not ideal): rebase -s C -d Z creates divergence

Successor is in other places

      E # E: unstable
      |
Z D'  D # D: replaced by D'
 \|  /
  B C
  |/
  A

Option 1: rebase -s C -d Z aborts (current default behavior)
Option 2: rebase -s C -d Z creates diverange (with experimental.allowdivergence=True)
Option 3: rebase -s C -d Z --evolve rebases roots to destination and evolves others

C'E'
| |
Z D'
 \|
  B
  |
  A

Related issues

Mostly about how to deal with the "Successor is also in a rebase set" case.

-  ⇤ ← Revision 2 as of 2016-12-21 21:54:47 → 
  Size: 1797
  Editor: JunWu
  Comment:
+   ← Revision 9 as of 2016-12-24 21:37:25 → ⇥
  Size: 2831
  Editor: JunWu
  Comment: Add Augie's idea on issue5300
-Deletions are marked like this.
+Additions are marked like this.
 Line 1:
-= Rebase with changesets in rebaseset =
+= Rebase with obsoleted changesets in rebaseset =
-Line 15:
+Line 14:
-  Z   F # F: unstable
  |   |
  D'  D # D: replaced by D'
  |  /
+  Z E # E: unstable
  | |
 D' D # D: replaced by D'
  | |
-Line 27:
+Line 26:
-  F'
+  E'
-Line 50:
+Line 49:
- * Option 1: {{{rebase -s C -d Z}}} creates new markers, avoid potential merge conflicts (in case the user knows there will be a conflict and wants to edit D"' before rebase E').
+ * Option 1 (rebase markers): {{{rebase -s C -d Z}}} creates new markers, avoid potential merge conflicts (in case the user knows there will be a conflict and wants to edit D"' before rebase E'). Like Option 5, plus creating new markers. The main concern is marker explosion.
-Line 64:
+Line 63:
- * Option 2: {{{rebase -s C -d Z}}} auto rebases E' to D"', does not create D", and does not create new markers. Like running "hg evolve" after Option 1.
+ * Option 2: {{{rebase -s C -d Z (with some flag?)}}} skips {{{precursors(rebaseset)::}}} in rebaseset. In the example case, E remains at the old position. The user need to run another {{{rebase -s E -d D"'}}} to move E. There is no {{{D"}}} like Option 1 so the user cannot create divergence easily and conflict of rebasing E can be handled later. The downside is not intuitive - users may expect C to be "extinct" (i.e. not shown up in {{{hg sl}}}) after {{{rebase -s C -d ...}}}.

{{{

    D"'
    |
    C'E # E: unstable
   / /
  Z D D' # D: replaced by D'; D': replaced by D"'
  | |/
  B C # C: replaced by C'
  |/
  A
}}}

 * Option 3: {{{rebase -s C -d Z --evolve}}} auto rebases E' to D"', does not create D", and does not create new markers. Like running "hg evolve" after Option 1. This is consistent with the {{{--evolve}}} flag below.
-Line 69:
+Line 83:
-    D"
+    D"'
-Line 78:
+Line 92:
- * Option 3 (not ideal): {{{rebase -s C -d Z}}} aborts (current default behavior)
 * Option 4 (not ideal): {{{rebase -s C -d Z}}} creates divergence (current behavior with experimental.allowdivergence=1)
+ * Option 4 (current behavior, not ideal): {{{rebase -s C -d Z}}} aborts
 * Option 5 (current behavior with {{{experimental.allowdivergence=1}}}, not ideal): {{{rebase -s C -d Z}}} creates divergence
-Line 86:
+Line 99:
-      E
+      E # E: unstable
-Line 97:
+Line 110:
-  * Option 3: (Do we have other options) ?
+  * Option 3: {{{rebase -s C -d Z --evolve}}} rebases roots to destination and evolves others

{{{
C'E'
| |
Z D'
 \|
  B
  |
  A
}}}
-Line 101:
+Line 125:
+Mostly about how to deal with the "Successor is also in a rebase set" case.
-Line 102:
+Line 128:
+ * https://bz.mercurial-scm.org/5300

Diff for "CEDRebase"