pushrebase: cleanup phase handling

Summary:
It turns out that bundlerepo uses the underlying phase boundaries, so the
added changesets show up with the same phase as their nearest ancestor that's
already in the repository.  This behavior is confusing and inconsistent with
what happens when the bundle is actually applied: retracting the draft boundary
over the new commits.

This makes a copy of the phase cache so that changes in the bundlerepo don't
affect the real one and then retracts the draft boundary like would happen
when the bundle is applied normally.

If this general solution looks OK, I'll submit an upstream patch that makes
bundlerepo behave this way always, which will make it match the behavior that
would be seen when using ##hg unbundle##.

Test Plan: ##run-tests.py##

Reviewers: pyd, durham

Reviewed By: durham

Subscribers: calvinb, rmcelroy, daviser, mpm, davidsp, sid0, akushner, pyd, durham

Differential Revision: https://phabricator.fb.com/D1733166

Signature: t1:1733166:1420502423:f57e2fff8fe47293ecab1ac4f6efdd0507c9c7b5
This commit is contained in:
Eric Sumner 2015-01-05 15:50:59 -08:00
parent f5303c01ab
commit 4092b99234

View File

@ -52,6 +52,9 @@ def validaterevset(repo, revset):
if not repo.revs(revset):
raise util.Abort(_('nothing to rebase'))
if repo.revs('%r and public()', revset):
raise util.Abort(_('cannot rebase public changesets'))
if repo.revs('%r and merge()', revset):
raise util.Abort(_('cannot rebase merge changesets'))
@ -248,10 +251,6 @@ def _buildobsolete(replacements, oldrepo, newrepo):
for oldrev, newrev in replacements.items()
if newrev != oldrev]
# TODO: make sure these weren't public originally
for old, new in markers:
old.mutable = lambda *args: True
obsolete.createmarkers(newrepo, markers)
def _addpushbackchangegroup(repo, reply, outgoing):