The whole rebase function is gargantuan and this computation is almost 100 lines
long. We extract it in a dedicated function as it is independent from the rest
of the rebase code.
Having it in its own function will make it easier to rework the default
destination logic.
The update logic have grow more and more complicated over time (eg bookmark
movement, new destination logic, warning on other head, etc). The rebase
extension was reimplementing its own basic version of update to be used by 'hg
pull --rebase'. We remove the custom code and use a combination of higher level
functions.
A test is added to check that the update is properly warning about other branch
heads.
I recently discovered that 'hg pull --rebase' was also running an update. And it
was running it in all cases as long as the update would move the working copy
somewhere else...
This felt wrong and it actually is. This 'update' call is introduced in
8bea699a182c. In that commit the intent is very clear. The update should happen
only when there was nothing to rebase. The implementation did not check if a
rebase was performed because, at that time, rebase would always leave you on the
top most changeset. Being on that top most changeset result in a no-op update
and the step was skipped.
However 642dc7838453d changed rebase behavior to preserve the working copy
parent, so if we are not on a head at pull time, the code performs both a rebase
and an update.
This changeset introduce a test for this case and restore the intended behavior.
There are other issues with this custom update code but they will be addressed
in later changeset (eg: own destination logic, lack of heads warning).
I'm not super happy with the explicitly comparison 'rebase(...) == 1' but a
later series will have a cleaner way to handle it anyway (while making 'rebase'
pick its default destination like 'merge').
Rather than look for the lowest revision, see if the rebase state is tracking
the parents of this revision. Otherwise we can't handle multiple revisions in
one rebase that includes a merge revision.
Fixes issue5044.
Inhibit, one of evolve's extension, would like to change the way rebase works
with obsolete changesets. During a rebase with inhibit, the inhibition of the
obsolescence markers should be lifted for the rebase.
With this small refactoring, inhibit and can wrap the _filterobsoleterevs
function to lift inhibition cleanly and at the same time this change makes
rebases' code more legible.
Before this patch rebase would create divergence when you were rebasing obsolete
changesets on a destination not containing one of its successors.
This patch introduces rebase.allowdivergence to explicitly allow
divergence creation with rebase.
This patch is a refactoring of the code skipping obsolete changesets already
present in destination. It makes the following patches more legible.
Instead of passing all the revs to be rebased to _computeobsoletenotrebased,
we only pass the obsolete revisions of the rebaseset.
Previous patch introduced 'revset.predicate' decorator to register
revset predicate function easily.
But it shouldn't be used in extension directly, because it registers
specified function immediately. Registration itself can't be restored,
even if extension loading fails after that.
Therefore, registration should be delayed until 'uisetup()' or so.
This patch uses 'extpredicate' decorator derived from 'delayregistrar'
to register predicate in extension easily.
This patch also tests whether 'registrar.delayregistrar' avoids
function registration if 'setup()' isn't invoked on it, because
'extpredicate' is the first user of it.
Before this patch, when rebasing a set of obsolete revisions that were plain
pruned or already present in the destination, we were displaying:
abort: no matching revisions
This was not very helpful to understand what was going on, instead we replace
the error message by:
abort: all requested changesets have equivalents or were marked as obsolete
(to force the rebase, set the config experimental.rebaseskipobsolete to False)
In 6e6b18aab8b2, I made the mistake of moving the step "clearing the status
after a rebase" to inside the rebase transaction.
This was wrong, since we don't want to clear the status (and the rebase state)
if something went wrong during the transaction: if something goes wrong we
want to keep the rebase state to be able to abort.
It broke rebase with evolve + inhibit.
localrepo.parents() has relatively few users, and most of those were
actually implicitly looking at the wctx, which is now made explicit
via repo[None].
Before this patch we were using the old api bookmarks.write instead of
bookmarks.recordchange at the end of rebase operations.
We move clearstatus within the transaction to make it easier for extensions
that wrap transactions operations.
This patch avoids unnecessary conflicts to resolve during rebase for the users
of changeset evolution.
This patch modifies rebase to skip obsolete commits with no successor.
It introduces a new rebase state 'revpruned' for these revisions that are
being skipped and a new message to inform the user of what is happening.
This feature is gated behind the config flag experimental.rebaseskipobsolete
When an obsolete commit is skipped, the output is:
note: not rebasing 7:360bbaa7d3ce "O", it has no successor
So far pullrebase function has always returned None value, no matter
what orig function returned. This behaviour made impossible for
pull to change returned value from mercurial process (it has always
ended with 0 value by default). This patch makes pullrebase returning
with returned value from orig.
--collapse will do that rebase doesn't commit until the final commit. The lack
of a new commit would make it look like the rebase didn't contribute any
changes.
Instead, only warn about no commits when not using --collapse.
Now, 'dirstate.write(tr)' delays writing in-memory changes out, if a
transaction is running.
This may cause treating this revision as "the first bad one" at
bisecting in some cases using external hook process inside transaction
scope, because some external hooks and editor process are still
invoked without HG_PENDING and pending changes aren't visible to them.
'dirstate.write()' callers below in localrepo.py explicitly use 'None'
as 'tr', because they can assume that no transaction is running:
- just before starting transaction
- at closing transaction, or
- at unlocking wlock
Refactoring by reduce the scope of the try catch block so that it only captures
what it needs. I could have made it smaller but another patch in the series
will add onto it.
When a user's repository is in an unfinished rebase state and they choose to
abort, at a minimum, the repo should be out of that state. We've found
situations where the user could not leave the state unless manually deleting the
rebasestate file. This fix ensures that no matter what exception may be raised
during the abort, the rebase state file will be deleted, the user will be out of
the rebase state and they can get their repository into a workable condition.
After rebasing a set of changes onto a public changeset and having the first one
be skipped, if you try to abort, the operation fails. This fix adds a check to
disallow the target rev into the dstates list within the abort function. This
list is checked for immutable states before the rest of abort does its thing.
