( )⚙ D1139 restack: use multidest rebase to implement restack

This is an archive of the discontinued Mercurial Phabricator instance.

Differential D1139

restack: use multidest rebase to implement restack
ClosedPublic

Authored by quark on Oct 17 2017, 1:52 AM.
Tags
None
Subscribers
durham, kulshrax

Details

Reviewers
durham
Group Reviewers
Restricted Project
Commits
rFBHGX3a7053b51da8: restack: use multidest rebase to implement restack
Summary

With the multidest rebase (D470), restack could be implemented as specifying
the source (orphan() - obsolete()) and a revset specifying destination for
each source revision.

This patch changes restack implementation to use that. The revset is
implemented as a private function _destrestack, like _destrebase in
rebase.py.

Most test changes are because the topo-sort in rebase.py removes some
unnecessary steps. So the resulting revision numbers are smaller.

There is one interesting test case that gets changed:

   D
   |      # amend: B1 -> B2 -> B1
B2 B1 B3  # amend: B1 -> B3
 \ | /
   A

Previously, restack will move D to be on top of B3. Now restack will not
move it because D is considered stable (not orphaned) since none of its
ancestors are obsoleted. The new behavior seems to be more desirable.

More tests are added to test restack source revisions (should be in a same
stack) and some "prune" cases.

The transaction logic is also made more robust so test-copytrace-amend.t
does not cause a broken rebase state.

Since the rebase operation runs in a same rebase state, restack can be
continued via rebase --continue correctly after resolving merge conflicts.
This is reflected in a newly added test.

Test Plan

With hg-dev, run ./script/unit.py

Diff Detail

Repository
rFBHGX Facebook Mercurial Extensions
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

quark created this revision.Oct 17 2017, 1:52 AM
Herald added a reviewer: Restricted Project. · View Herald TranscriptOct 17 2017, 1:52 AM
quark edited the summary of this revision. (Show Details)Oct 17 2017, 2:31 AM
quark updated this revision to Diff 2892.
quark updated this revision to Diff 2893.
quark edited the summary of this revision. (Show Details)Oct 17 2017, 1:24 PM
quark updated this revision to Diff 2932.
quark added inline comments.Oct 17 2017, 2:44 PM
hgext3rd/fbamend/revsets.py
108

This could be simplified to break.

kulshrax added a subscriber: kulshrax.Oct 17 2017, 3:44 PM

Does this mean that the entire restack will continue after a merge conflict with hg rebase --continue? (Since the entire thing is just a single rebase call now.) If so, that's really great.

hgext3rd/fbamend/restack.py
24–25

Would it also make sense to have a revset that finds all of the draft changesets related to the current stack, and then use that here?

If I'm not mistaken, this would also allow restack to just be an alias to hg rebase with the appropriate source and destination revsets.

32–33

The current behavior of restack is to check all descendants if the working copy parent is public.

For example:

  o  7ca158  kulshrax
 /   E
|
| o  17831b  kulshrax
| |  E
| |
| x  485b07 (Amended as 7ca158)  kulshrax
|/   D
|
o  a3cc13  kulshrax
.  C
.
@  d97f1c  kulshrax
|  A
~

results in:

rebasing 7:17831bce1ba1 "E"
17831bce1ba1 -> 697867a73131 "E"
hgext3rd/fbamend/revsets.py
67

Could you be more explicit about what a "restack destination" is here?

99

Is the top successor from the split necessarily a head? (What happens if it has another, unrelated child?)

114–116

Just curious: what are your thoughts for how to resolve divergence here? The old behavior of picking the larger rev number was very much an arbitrary choice, since there didn't seem to be other good criteria for picking a divergent successor

kulshrax added a comment.EditedOct 17 2017, 4:00 PM

Also, are you going to modify hg next --rebase to use this new restack functionality? Presently it just calls _restackonce() (which itself is not ideal for that case since it rebases all of the children at each level of the stack rather than just the one on the path to the destination).

quark added a comment.EditedOct 17 2017, 4:24 PM
In D1139#19499, @kulshrax wrote:

Does this mean that the entire restack will continue after a merge conflict with hg rebase --continue? (Since the entire thing is just a single rebase call now.) If so, that's really great.

Yes. Good point. I'll add a test.

Also, are you going to modify hg next --rebase to use this new restack functionality? Presently it just calls '_restackonce()` (which itself is not ideal for that case since it rebases all of the children at each level of the stack rather than just the one on the path to the destination).

Ideally yes if I can figure out a neat way to calculate the source revisions.

hgext3rd/fbamend/revsets.py
67

It's for the --dest flag like rebase -r REV -d _destrestack(REV).

rebase command calls it as "destination". Maybe it should be "the new base".

99

Good question!

Here we treat them the same as the "divergent" case - picking the largest , which could be wrong.

In the future if we choose to do nothing for "divergent" case, we could avoid that "wrong" behavior, although it feels not as smart as it can be.

I think split requires a lot of effort to handle perfectly. rebase.py itself does suboptimal things regarding on split as of today. Maybe it could be simplified by recording the top split commit as "primary rewrite edge" and other split commits as "secondary" at the time of split. But that is a huge change to obsstore today.

114–116

It could be doing nothing here but prompt the user to run a hg resolve-like command to resolve the divergence first. The resolution could be a merge, or pick one from candidates.

quark edited the summary of this revision. (Show Details)Oct 18 2017, 3:45 PM
quark updated this revision to Diff 2993.
durham requested changes to this revision.Oct 31 2017, 12:44 PM
durham added a subscriber: durham.

Changes requested for the lock issue. Otherwise looks good

hgext3rd/fbamend/restack.py
32–33

+1 was this an intentional behavior change? I can see it going either way

33–45

Moving the lock down to here means the revset computations above could be completely wrong now right? Heck, the working copy parent could be different at this point.

35

Should we print a "nothing to restack" message? Seems odd to be a complete no-op

This revision now requires changes to proceed.Oct 31 2017, 12:44 PM
quark added a comment.Nov 1 2017, 2:47 PM

@kulshrax I took a look at restackonce and it does not benefit from the multi-dest feature - It only has a single destination. So I'm leaving restackonce unchanged for now.

hgext3rd/fbamend/restack.py
33–45

Good catch.

35

Maybe. The old behavior is to print nothing.

quark updated this revision to Diff 3195.Nov 1 2017, 3:54 PM
durham accepted this revision.Nov 2 2017, 11:58 AM
This revision is now accepted and ready to land.Nov 2 2017, 11:58 AM
Closed by commit rFBHGX3a7053b51da8: restack: use multidest rebase to implement restack (authored by quark). · Explain WhyNov 2 2017, 3:06 PM
This revision was automatically updated to reflect the committed changes.

Revision Contents
Changeset List

Diff 3195

hgext3rd/fbamend/restack.py

# restack.py - rebase to make a stack connected again # restack.py - rebase to make a stack connected again
# #
# Copyright 2013 Facebook, Inc. # Copyright 2013 Facebook, Inc.
# #
# This software may be used and distributed according to the terms of the # This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version. # GNU General Public License version 2 or any later version.
from __future__ import absolute_import from __future__ import absolute_import
from collections import deque from mercurial.i18n import _
from mercurial import ( from mercurial import (
cmdutil,
commands, commands,
error, revsetlang,
) )
from . import common from hgext import rebase
def restack(ui, repo, rebaseopts=None): def restack(ui, repo, rebaseopts=None):
"""Repair a situation in which one or more changesets in a stack """Repair a situation in which one or more changesets in a stack
have been obsoleted (thereby leaving their descendants in the stack have been obsoleted (thereby leaving their descendants in the stack
unstable) by finding any such changesets and rebasing their descendants unstable) by finding any such changesets and rebasing their descendants
onto the latest version of each respective changeset. onto the latest version of each respective changeset.
""" """
if rebaseopts is None: rebaseopts = (rebaseopts or {}).copy()
rebaseopts = {}
kulshraxUnsubmitted
Not Done

Would it also make sense to have a revset that finds all of the draft changesets related to the current stack, and then use that here?

If I'm not mistaken, this would also allow restack to just be an alias to hg rebase with the appropriate source and destination revsets.

kulshrax: Would it also make sense to have a revset that finds all of the draft changesets related to the…
# TODO: Remove config override after https://phab.mercurial-scm.org/D1063
config = {('experimental', 'rebase.multidest'): True}
with ui.configoverride(config), repo.wlock(), repo.lock():
# Find drafts connected to the current stack via either changelog or
# obsolete graph. Note: "draft() & ::." is optimized by D441.
# 1. Connect drafts via changelog
kulshraxUnsubmitted
Not Done

The current behavior of restack is to check all descendants if the working copy parent is public.

For example:

  o  7ca158  kulshrax
 /   E
|
| o  17831b  kulshrax
| |  E
| |
| x  485b07 (Amended as 7ca158)  kulshrax
|/   D
|
o  a3cc13  kulshrax
.  C
.
@  d97f1c  kulshrax
|  A
~

results in:

rebasing 7:17831bce1ba1 "E"
17831bce1ba1 -> 697867a73131 "E"
kulshrax: The current behavior of restack is to check all descendants if the working copy parent is…
durhamUnsubmitted
Not Done

+1 was this an intentional behavior change? I can see it going either way

durham: +1 was this an intentional behavior change? I can see it going either way
revs = list(repo.revs('(draft() & ::.)::'))
if not revs:
durhamUnsubmitted
Not Done

Should we print a "nothing to restack" message? Seems odd to be a complete no-op

durham: Should we print a "nothing to restack" message? Seems odd to be a complete no-op
quarkAuthorUnsubmitted
Not Done

Maybe. The old behavior is to print nothing.

quark: Maybe. The old behavior is to print nothing.
# "." is probably public. Check its direct children.
revs = repo.revs('draft() & children(.)')
if not revs:
ui.status(_('nothing to restack\n'))
return 1
# 2. Connect revs via obsolete graph
revs = list(repo.revs('successors(%ld)+allpredecessors(%ld)',
revs, revs))
# 3. Connect revs via changelog again to cover missing revs
revs = list(repo.revs('(draft() & ::%ld)::', revs))
durhamUnsubmitted
Not Done

Moving the lock down to here means the revset computations above could be completely wrong now right? Heck, the working copy parent could be different at this point.

durham: Moving the lock down to here means the revset computations above could be completely wrong now…
quarkAuthorUnsubmitted
Not Done

Good catch.

quark: Good catch.
rebaseopts['rev'] = [revsetlang.formatspec('%ld', revs)]
rebaseopts['dest'] = '_destrestack(SRC)'
with repo.wlock(), repo.lock(): rebase.rebase(ui, repo, **rebaseopts)
cmdutil.checkunfinished(repo)
cmdutil.bailifchanged(repo)
# Find the latest version of the changeset at the botom of the
# current stack. If the current changeset is public, simply start
# restacking from the current changeset with the assumption
# that there are non-public changesets higher up.
base = repo.revs('::. & draft()').first()
latest = (common.latest(repo, base) if base is not None
else repo['.'].rev())
targets = _findrestacktargets(repo, latest)
with repo.transaction('restack') as tr:
# Attempt to stabilize all changesets that are or will be (after
# rebasing) descendants of base.
for rev in targets:
try:
common.restackonce(ui, repo, rev, rebaseopts)
except error.InterventionRequired:
tr.close()
raise
# Ensure that we always end up on the latest version of the # Ensure that we always end up on the latest version of the
# current changeset. Usually, this will be taken care of # current changeset. Usually, this will be taken care of
# by the rebase operation. However, in some cases (such as # by the rebase operation. However, in some cases (such as
# if we are on the precursor of the base changeset) the # if we are on the precursor of the base changeset) the
# rebase will not update to the latest version, so we need # rebase will not update to the latest version, so we need
# to do this manually. # to do this manually.
successor = repo.revs('allsuccessors(.)').last() successor = repo.revs('allsuccessors(.)').last()
if successor is not None: if successor is not None:
commands.update(ui, repo, rev=successor) commands.update(ui, repo, rev=successor)
def _findrestacktargets(repo, base):
"""Starting from the given base revision, do a BFS forwards through
history, looking for changesets with unstable descendants on their
precursors. Returns a list of any such changesets, in a top-down
ordering that will allow all of the descendants of their precursors
to be correctly rebased.
"""
childrenof = common.getchildrelationships(repo,
repo.revs('%d + allpredecessors(%d)', base, base))
# Perform BFS starting from base.
queue = deque([base])
targets = []
processed = set()
while queue:
rev = queue.popleft()
# Merges may result in the same revision being added to the queue
# multiple times. Filter those cases out.
if rev in processed:
continue
processed.add(rev)
# Children need to be added in sorted order so that newer
# children (as determined by rev number) will have their
# descendants of their precursors rebased before older children.
# This ensures that unstable changesets will always be rebased
# onto the latest visible successor of their parent changeset.
queue.extend(sorted(childrenof[rev]))
# Look for visible precursors (which are probably visible because
# they have unstable descendants) and successors (for which the latest
# non-obsolete version should be visible).
precursors = repo.revs('allpredecessors(%d)', rev)
successors = repo.revs('allsuccessors(%d)', rev)
# If this changeset has precursors but no successor, then
# if its precursors have children those children need to be
# rebased onto the changeset.
if precursors and not successors:
children = []
for p in precursors:
children.extend(childrenof[p])
if children:
queue.extend(children)
targets.append(rev)
# We need to perform the rebases in reverse-BFS order so that
# obsolescence information at lower levels is not modified by rebases
# at higher levels.
return reversed(targets)

hgext3rd/fbamend/revsets.py

# revsets.py - revset definitions # revsets.py - revset definitions
# #
# Copyright 2017 Facebook, Inc. # Copyright 2017 Facebook, Inc.
# #
# This software may be used and distributed according to the terms of the # This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version. # GNU General Public License version 2 or any later version.
from __future__ import absolute_import from __future__ import absolute_import
from mercurial.node import nullrev
from mercurial import ( from mercurial import (
obsutil, obsutil,
phases,
registrar, registrar,
revset, revset,
smartset, smartset,
) )
revsetpredicate = registrar.revsetpredicate() revsetpredicate = registrar.revsetpredicate()
def _calculateset(repo, subset, x, f): def _calculateset(repo, subset, x, f):
return _calculateset(repo, subset, x, f) return _calculateset(repo, subset, x, f)
@revsetpredicate('allprecursors(set)') @revsetpredicate('allprecursors(set)')
@revsetpredicate('allpredecessors(set)') @revsetpredicate('allpredecessors(set)')
def allpredecessors(repo, subset, x): def allpredecessors(repo, subset, x):
"""All changesets which are predecessors for given set, recursively""" """All changesets which are predecessors for given set, recursively"""
f = lambda nodes: obsutil.allpredecessors(repo.obsstore, nodes) f = lambda nodes: obsutil.allpredecessors(repo.obsstore, nodes)
return _calculateset(repo, subset, x, f) return _calculateset(repo, subset, x, f)
@revsetpredicate('_destrestack(SRC)')
def _destrestack(repo, subset, x):
"""restack destination for given single source revision"""
kulshraxUnsubmitted
Not Done

Could you be more explicit about what a "restack destination" is here?

kulshrax: Could you be more explicit about what a "restack destination" is here?
quarkAuthorUnsubmitted
Not Done

It's for the --dest flag like rebase -r REV -d _destrestack(REV).

rebase command calls it as "destination". Maybe it should be "the new base".

quark: It's for the `--dest` flag like `rebase -r REV -d _destrestack(REV)`. rebase command calls it…
unfi = repo.unfiltered()
obsoleted = unfi.revs('obsolete()')
getparents = unfi.changelog.parentrevs
getphase = unfi._phasecache.phase
nodemap = unfi.changelog.nodemap
src = revset.getset(repo, subset, x).first()
# Empty src or already obsoleted - Do not return a destination
if not src or src in obsoleted:
return smartset.baseset()
# Find the obsoleted "base" by checking source's parent recursively
base = src
while base not in obsoleted:
base = getparents(base)[0]
# When encountering a public revision which cannot be obsoleted, stop
# the search early and return no destination. Do the same for nullrev.
if getphase(repo, base) == phases.public or base == nullrev:
return smartset.baseset()
# Find successors for given base
# NOTE: Ideally we can use obsutil.successorssets to detect divergence
# case. However it does not support cycles (unamend) well. So we use
# allsuccessors and pick non-obsoleted successors manually as a workaround.
basenode = repo[base].node()
succnodes = [n for n in obsutil.allsuccessors(repo.obsstore, [basenode])
if (n != basenode and n in nodemap
and nodemap[n] not in obsoleted)]
# In case of a split, only keep its heads
succrevs = list(unfi.revs('heads(%ln)', succnodes))
kulshraxUnsubmitted
Not Done

Is the top successor from the split necessarily a head? (What happens if it has another, unrelated child?)

kulshrax: Is the top successor from the split necessarily a head? (What happens if it has another…
quarkAuthorUnsubmitted
Not Done

Good question!

Here we treat them the same as the "divergent" case - picking the largest , which could be wrong.

In the future if we choose to do nothing for "divergent" case, we could avoid that "wrong" behavior, although it feels not as smart as it can be.

I think split requires a lot of effort to handle perfectly. rebase.py itself does suboptimal things regarding on split as of today. Maybe it could be simplified by recording the top split commit as "primary rewrite edge" and other split commits as "secondary" at the time of split. But that is a huge change to obsstore today.

quark: Good question! Here we treat them the same as the "divergent" case - picking the largest…
if len(succrevs) == 0:
# Prune - Find the first non-obsoleted ancestor
while base in obsoleted:
base = getparents(base)[0]
if base == nullrev:
# Root node is pruned. The new base (destination) is the
# virtual nullrev.
return smartset.baseset([nullrev])
quarkAuthorUnsubmitted
Not Done

This could be simplified to break.

quark: This could be simplified to `break`.
return smartset.baseset([base])
elif len(succrevs) == 1:
# Unique visible successor case - A valid destination
return smartset.baseset([succrevs[0]])
else:
# Multiple visible successors - Choose the one with a greater revision
# number. This is to be compatible with restack old behavior. We might
# want to revisit it when we introduce the divergence concept to users.
kulshraxUnsubmitted
Not Done

Just curious: what are your thoughts for how to resolve divergence here? The old behavior of picking the larger rev number was very much an arbitrary choice, since there didn't seem to be other good criteria for picking a divergent successor

kulshrax: Just curious: what are your thoughts for how to resolve divergence here? The old behavior of…
quarkAuthorUnsubmitted
Not Done

It could be doing nothing here but prompt the user to run a hg resolve-like command to resolve the divergence first. The resolution could be a merge, or pick one from candidates.

quark: It could be doing nothing here but prompt the user to run a `hg resolve`-like command to…
return smartset.baseset([max(succrevs)])

tests/test-copytrace-amend.t

$ hg mv a b $ hg mv a b
$ hg amend $ hg amend
warning: the changeset's children were left behind warning: the changeset's children were left behind
(use 'hg restack' to rebase them) (use 'hg restack' to rebase them)
$ hg rebase --restack $ hg rebase --restack
rebasing 2:ad25e018afa9 "mod a" rebasing 2:ad25e018afa9 "mod a"
merging b and a to b merging b and a to b
rebasing 3:ba0395f0e180 "delete a" rebasing 3:ba0395f0e180 "delete a"
transaction abort!
rollback completed
abort: a@ba0395f0e180: not found in manifest! abort: a@ba0395f0e180: not found in manifest!
[255] [255]
$ hg rebase --abort $ hg rebase --abort
rebase aborted (no revision is removed, only broken state is cleared) saved backup bundle to $TESTTMP/repo/.hg/strip-backup/3fd0353a7967-a25c7d46-backup.hg (glob)
rebase aborted
$ cd .. $ cd ..
$ rm -rf repo $ rm -rf repo
Test amend copytrace can be disabled Test amend copytrace can be disabled
$ cat >> $HGRCPATH << EOF $ cat >> $HGRCPATH << EOF
> [copytrace] > [copytrace]
> enableamendcopytrace=false > enableamendcopytrace=false
> EOF > EOF

tests/test-fbamend-restack.t

| | @ 3 add d | | @ 3 add d
| | | | | |
+---x 2 add c +---x 2 add c
| | | |
x | 1 add b x | 1 add b
|/ |/
o 0 add a o 0 add a
$ hg rebase --restack $ hg rebase --restack
rebasing 3:47d2a3944de8 "add d"
rebasing 5:a43fcd08f41f "add c" (tip) rebasing 5:a43fcd08f41f "add c" (tip)
rebasing 6:49b119a57122 "add d" rebasing 3:47d2a3944de8 "add d"
$ showgraph $ showgraph
@ 8 add d @ 7 add d
| |
o 7 add c o 6 add c
| |
o 4 add b o 4 add b
| |
o 0 add a o 0 add a
Test what happens if there is no base commit found. The command should Test what happens if there is no base commit found. The command should
fix up everything above the current commit, leaving other commits fix up everything above the current commit, leaving other commits
below the current commit alone. below the current commit alone.
| o 3 add b | o 3 add b
|/ |/
| o 2 add c | o 2 add c
| | | |
| x 1 add b | x 1 add b
|/ |/
o 0 add a o 0 add a
$ hg unamend $ hg unamend
$ hg up -C 1 $ hg up -C 3
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ showgraph $ showgraph
o 3 add b @ 3 add b
| |
| o 2 add c | o 2 add c
| | | |
| @ 1 add b
|/
o 0 add a
$ hg rebase --restack
rebasing 2:4538525df7e2 "add c"
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ showgraph
o 5 add c
|
@ 3 add b
|
| o 1 add b | o 1 add b
|/ |/
o 0 add a o 0 add a
Revision 2 "add c" is already stable (not orphaned) so restack does nothing:
$ hg rebase --restack
nothing to rebase - empty destination
Test recursive restacking -- basic case. Test recursive restacking -- basic case.
$ reset $ reset
$ mkcommit a $ mkcommit a
$ mkcommit b $ mkcommit b
$ mkcommit c $ mkcommit c
$ mkcommit d $ mkcommit d
$ hg up 1 $ hg up 1
0 files updated, 0 files merged, 2 files removed, 0 files unresolved 0 files updated, 0 files merged, 2 files removed, 0 files unresolved
| | o 3 add d | | o 3 add d
| | | | | |
+---x 2 add c +---x 2 add c
| | | |
@ | 1 add b @ | 1 add b
|/ |/
o 0 add a o 0 add a
$ hg rebase --restack $ hg rebase --restack
rebasing 3:47d2a3944de8 "add d"
rebasing 5:a43fcd08f41f "add c" (tip) rebasing 5:a43fcd08f41f "add c" (tip)
rebasing 6:49b119a57122 "add d" rebasing 3:47d2a3944de8 "add d"
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ showgraph $ showgraph
o 8 add d o 7 add d
| |
o 7 add c o 6 add c
| |
@ 4 add b @ 4 add b
| |
| x 1 add b | x 1 add b
|/ |/
o 0 add a o 0 add a
Test recursive restacking -- more complex case. This test is designed to Test recursive restacking -- more complex case. This test is designed to
| | o 3 add d | | o 3 add d
| | | | | |
+---x 2 add c +---x 2 add c
| | | |
@ | 1 add b @ | 1 add b
|/ |/
o 0 add a o 0 add a
$ hg rebase --restack $ hg rebase --restack
rebasing 10:9f2a7cefd4b4 "add h"
rebasing 6:2a79e3a98cd6 "add f" rebasing 6:2a79e3a98cd6 "add f"
rebasing 3:47d2a3944de8 "add d"
rebasing 8:a43fcd08f41f "add c" rebasing 8:a43fcd08f41f "add c"
rebasing 11:604f34a1983d "add g" (tip) rebasing 11:604f34a1983d "add g" (tip)
rebasing 12:e1df23499b99 "add h" rebasing 3:47d2a3944de8 "add d"
rebasing 14:49b119a57122 "add d" rebasing 10:9f2a7cefd4b4 "add h"
1 files updated, 0 files merged, 0 files removed, 0 files unresolved 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ showgraph $ showgraph
o 18 add d o 16 add h
| |
| o 17 add h | o 15 add d
| | | |
| o 16 add g o | 14 add g
|/ |/
o 15 add c o 13 add c
| |
| o 13 add f | o 12 add f
| | | |
| o 7 add e | o 7 add e
|/ |/
@ 4 add b @ 4 add b
| |
| x 1 add b | x 1 add b
|/ |/
o 0 add a o 0 add a
Suboptimal case: restack rebases "D" twice Restack does topological sort and only rebases "D" once:
$ reset $ reset
$ hg debugdrawdag<<'EOS' $ hg debugdrawdag<<'EOS'
> D > D
> | > |
> C > C
> | > |
> B > B
| o 3 D | o 3 D
| | | |
| x 2 C | x 2 C
| | | |
| x 1 B | x 1 B
|/ |/
o 0 A o 0 A
$ hg rebase --restack $ hg rebase --restack
rebasing 3:f585351a92f8 "D" (D)
rebasing 5:ca53c8ceb284 "C" rebasing 5:ca53c8ceb284 "C"
rebasing 7:4da953fe10f3 "D" rebasing 3:f585351a92f8 "D" (D)
$ showgraph $ showgraph
o 9 D o 8 D
| |
o 8 C o 7 C
| |
@ 6 B3 @ 6 B3
| |
| x 4 B2 | x 4 B2
|/ |/
| x 3 D | x 3 D
| | | |
| x 2 C | x 2 C
| | | |
| x 1 B | x 1 B
|/ |/
o 0 A o 0 A
Restack will only restack the "current" stack and leave other stacks untouched.
$ reset
$ hg debugdrawdag<<'EOS'
> D H K
> | | |
> B C F G J L # amend: B -> C
> |/ |/ |/ # amend: F -> G
> A E I Z # amend: J -> L
> EOS
$ hg phase --public -r Z+I+A+E
$ hg update -q Z
$ hg rebase --restack
nothing to restack
[1]
$ hg update -q D
$ hg rebase --restack
rebasing 10:be0ef73c17ad "D" (D)
$ hg update -q G
$ hg rebase --restack
rebasing 11:cc209258a732 "H" (H)
$ hg update -q I
$ hg rebase --restack
rebasing 12:59760668f0e1 "K" (K)
$ rm .hg/localtags
$ showgraph
o 15 K
|
| o 14 H
| |
| | o 13 D
| | |
o | | 9 L
| | |
| o | 7 G
| | |
| | o 5 C
| | |
| | | o 3 Z
| | |
@ | | 2 I
/ /
o / 1 E
/
o 0 A
The "prune" cases.
$ reset
$ hg debugdrawdag<<'EOS'
> D E
> |/
> C
> | # amend: F -> F2
> B G H # prune: A, C, F2
> | |/
> A F F2
> EOS
$ hg update -q B
$ hg rebase --restack
rebasing 3:112478962961 "B" (B)
rebasing 7:f585351a92f8 "D" (D)
rebasing 8:78d2dca436b2 "E" (E tip)
$ hg update -q H
$ hg rebase --restack
rebasing 4:8fdb2c1feb20 "G" (G)
rebasing 5:02ac06fe83b9 "H" (H)
$ rm .hg/localtags
$ showgraph
@ 13 H
o 12 G
o 11 E
|
| o 10 D
|/
o 9 B
Restack could resume after resolving merge conflicts.
$ reset
$ hg debugdrawdag<<'EOS'
> F G # F/C = F # cause conflict
> | | # G/E = G # cause conflict
> B C D E # amend: B -> C
> |/ |/ # amend: D -> E
> | /
> | /
> | /
> |/
> A
> EOS
$ hg update -q F
$ hg rebase --restack
rebasing 5:ed8545a5c22a "F" (F)
merging C
warning: conflicts while merging C! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
[1]
$ rm .hg/localtags
$ echo R > C
$ hg resolve --mark -q
continue: hg rebase --continue
$ hg rebase --continue
rebasing 5:ed8545a5c22a "F"
rebasing 6:4d1ef7d890c5 "G" (tip)
merging E
warning: conflicts while merging E! (edit, then use 'hg resolve --mark')
unresolved conflicts (see hg resolve, then hg rebase --continue)
[1]
$ echo R > E
$ hg resolve --mark -q
continue: hg rebase --continue
$ hg rebase --continue
already rebased 5:ed8545a5c22a "F" as 2282fe522d5c
rebasing 6:4d1ef7d890c5 "G"
$ showgraph
o 8 G
|
| @ 7 F
| |
o | 4 E
| |
| o 2 C
|/
o 0 A