|
Size: 2831
Comment: Add Augie's idea on issue5300
|
← Revision 18 as of 2017-08-31 18:50:17 ⇥
Size: 3529
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from ChangesetEvolutionDevelRebase | |
| Line 6: | Line 7: |
It needs merging with [[ChangesetEvolutionDevel#Using_Obsolescence_Marker_during_Rebase|existing info regarding rebase on the devel page]] |
|
| Line 40: | Line 43: |
| E # E: unstable | |
E # E: unstable | |
| Line 49: | Line 52: |
| * 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. | * 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. |
| Line 52: | Line 61: |
| E' | |
E' | |
| Line 63: | Line 72: |
| * 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 ...}}}. | * 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 |
| Line 78: | Line 91: |
| * 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. | * 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. |
| Line 129: | Line 142: |
---- CategoryDeveloper CategoryEvolution |
Rebase with obsoleted changesets in rebaseset
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
This page is intended for developer
This page collects situations and discussion about rebase where the rebaseset contains obsoleted changesets.
It needs merging with existing info regarding rebase on the devel page
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
|/
AOption 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'
|/
AOption 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
|/
AOption 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.