## page was renamed from ChangesetEvolutionDevelRebase
= 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.

It needs merging with [[ChangesetEvolutionDevel#Using_Obsolescence_Marker_during_Rebase|existing info regarding rebase on the devel page]]

<<TableOfContents(2)>>

== 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. There is a couple of concerns:

   * marker explosion (needs explain)

   * user need to solve similar merge conflict for twice (D + D') (but same with common rebase behavior without obsmarkers)

   * power user can always exclude troublemarkers using revset manually to get "Option 2" behavior.

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

 * Option 2 (skip troublemakers): {{{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 ...}}}.

   * may confuse the user a bit since the old revision is still hanging around

   * power user cannot get "Option 1" behavior if they really want to

{{{

    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 (evolve): {{{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.

 * https://bz.mercurial-scm.org/4210
 * https://bz.mercurial-scm.org/5300

----
CategoryDeveloper CategoryEvolution