This wraps all the locations of dirstate.setparent with the appropriate
begin/endparentchange calls. This will prevent exceptions during those calls
from causing incoherent dirstates (issue4353).
No Mercurial DAG has ever (!) been drawn in a way where 'up to' would apply.
Instead, describe deliberatey vague and informal instead of seemingly precise
but not describing the essentials:
rebase the tree around the specified changeset without ancestors of dest
A common mistake can be to type 'hg rebase -i' to discover interactive history
editing. We add a -i/--interactive flag as discussed in the sprint and deprecate
it right away, but hint people using it to use histedit instead.
"editform" argument for "getcommiteditor" is decided according to the
format below:
EXTENSION[.COMMAND][.ROUTE]
- EXTENSION: name of extension
- COMMAND: name of command, if there are two or more commands in EXTENSION
- ROUTE: name of route, if there are two or more routes in COMMAND
This patch newly adds "merge" as ROUTE, to distinguish merge commits
from other.
This patch passes bool as "ctxorbool" to "mergeeditform", because
working context has always 2 parents at this point. Dropping the
second parent of non-merging commits is executed in "concludenode".
Unlike other patches in this series (e.g. for "hg commit"), this patch
doesn't add "normal.normal"/"normal.merge" style ROUTEs, because there
is no "merge" case in "collapse" ROUTE.
Before this patch, if both "--message" and "--collapse" are specified
for "hg rebase", "rebaes.normal" is used as "editform" unexpectedly.
Unlike patches before and after in this series for improvement, this
is bug fix patch.
We rely on the internal mechanism to commit the changeset in the right phase.
This similar to what the mq extension is doing.
This is an important change as we plan to includes phase movement within the
transaction. Avoiding phase movement from high-level code will avoid the
burden of transaction handling. It is also important to limit the need for
transaction handling as this limits the odds of people messing up. Most common
expected mess-up is code using a different transaction for changeset creation
and phase adjustment.
This patch passes 'editform' argument according to the format below:
EXTENSION[.COMMAND][.ROUTE]
- EXTENSION: name of extension
- COMMAND: name of command, if there are two or more commands in EXTENSION
- ROUTE: name of route, if there are two or more routes in COMMAND
In this patch:
- COMMAND is omitted
- 'normal' and 'collapse' are used as ROUTE
The defect was that copies were always duplicated against the target
revision, rather than the first parent of the revision being
rebased. This produced nominally correct results if changes were
rebased one at a time (or with --collapse), but was wrong if we
rebased a sequence of changesets which contained a sequence of copies.
The documentation says we exit 1 if we have nothing to do, so avoid
breaking that contract when we're passed an empty revset.
This was changed in http://www.selenic.com/hg/rev/1d4f2abc281b to
improve the error message; keep the improved message, just not the
abort.
Changes rebase conflict markers to say 'source' and 'dest' instead of
'local' and 'other'. This ends up looking like:
one
<<<<<<< dest: a3e5c7fd master - bob: "A commit to master"
master
=======
mine
>>>>>>> source: c7fda3e5 - durham: "A commit to my feature branch"
three
Some extensions set configuration settings that showed up in 'hg showconfig
--debug' with 'none' as source. That was confusing.
Instead, they will now tell which extension they come from.
This change tries to be consistent and specify a source everywhere - also where
it perhaps is less relevant.
Before this patch, "rebase --collapse --edit" without "--message" and
"--logfile" invokes editor twice unexpectedly:
1. explicit "ui.edit()" invocation in rebase extension itself
2. indirect invocation in "localrepository.commit()" with "editor =
commitforceeditor" assigned by "--edit" option
This patch uses indirect "commitforceeditor" invocation instead of
"ui.edit()" for "--collapse" without "--message" and "--logfile" to:
- suppress redundant the former invocation
- ensure editor invocation even when "--edit" is not specified
When the base is not found, we should not raise a traceback about a not defined
variable. This hides the real problem: the function rebasenode was (probably)
called wrong.
An AssertionError is raised to highlight that the caller of the function did
something wrong.
An alternative approach is to only assign None to the variable "base" and let
the merge mechanism raise an abort message. This was the behaviour for this
case before 544133bac670. But the only known case for this problem is when an
extension calls this function wrong. An AssertionError makes this clearer than
an abort message. When a different case is detected, the behaviour can be
improved then.
This patch also enhances "test-rebase-scenario-global.t", because "hg
rebase" hasn't been explicitly tested around editor invocation and
"--edit" option.
In the other hand, this patch doesn't enhance tests in "hg rebase
--collapse" case, because it is already tested in
"test-rebase-collapse.t".
Before it just said 'nothing to rebase'.
Now 'if "base" is an empty set:
abort: empty "base" revision set - can't compute rebase set
If the set of changesets to rebase can't be found from "base", it will fail as
before but with more explanation of what the problem was.
The name of the "base" option is not obvious - it is more like "samples
identifying the branch to rebase". The error messages for problems with the
specified "base" value will use that term and might thus also not be obvious,
but at least they are consistent with the option name. The name "base" will not
be used if the base only was specified implicitly as the working directory
parent.
Before, it just said 'nothing to rebase' in this case. Now, it aborts
mentioning the reason: 'empty "source" revision set'.
Specifying revisions that cannot be rebased is a 'soft' error, but specifying
an empty set deserves an abort that explains exactly what the problem is.
Before, it just said 'nothing to rebase' in this case. Now, it aborts
mentioning the reason: 'empty "rev" revision set'.
Specifying revisions that cannot be rebased is a 'soft' error, but specifying
an empty set deserves an abort that explains exactly what the problem is.
Rebasing with --collapse would leave the working copy on the parent of the
collapsed commit, instead of on the collapsed commit. This fixes that. Also
fixes a few tests that already covered this area but had bad data.
This also fixes issue3716 where bookmarks are not kept across rebases with
--collapse. I updated the test to cover that case as well.
When aborting a rebase where tip-1 is public, rebase would fail to undo the merge
state. This caused unexpected dirstate parents and also caused unshelve to
become unabortable (since it uses rebase under the hood).
The problem was that rebase uses -2 as a marker rev, and when it checked for
immutableness during the abort, -2 got resolved to the second to last entry in
the phase cache.
Adds a test for the fix. Add exception to phase code to prevent this in the
future.
Prior this changeset, rebasing a merge whose first parent was not in
the rebase lead to wrong and highly conflicting merge. See the in-line
comment for details.
Test have been updated with the data provided by the reported.
Prior to this changeset, rebase always left the working directory as a parent of
the last rebased changeset. The is dubious when, before the rebase, the working
directory was not a parent of the tip most rebased changeset.
With this changeset, we move the working directory back to its original parent.
If the original parent was rebased, we use it's successors.
This is a step toward solving issue3813 (rebase loses active bookmark if it's
not on a head)
This makes it possible to pass keepbranches and extrafn to rebase at
the same time, although nobody uses that functionality presently. This
is a precursor to keeping graft metadata.
Before this patch, "hg summary" may fail, when there is inconsistent
rebase state: for example, the root of rebase destination revisions
recorded in rebase state file is already stripped manually.
Mercurial earlier than 2.7 allows users to do anything other than
starting new rebase, even though current rebase is not finished or
aborted yet. So, such inconsistent rebase states may be left and
forgotten in repositories.
This patch catches RepoLookupError at restoring rebase state for
summary hook, and treat such state as "broken".
Before this patch, "rebase --abort"/"--continue" may fail, when rebase
state is inconsistent: for example, the root of rebase destination
revisions recorded in rebase state file is already stripped manually.
Mercurial earlier than 2.7 allows users to do anything other than
starting new rebase, even though current rebase is not finished or
aborted yet. So, such inconsistent rebase states may be left and
forgotten in repositories.
This patch catches RepoLookupError at restoring rebase state for
abort/continue, and treat such state as "broken".
This saves us a relatively superfluous status check for pull --rebase (if
rebase runs, it'll check for a clean working directory anyway), and brings hg
pull --rebase closer to hg pull && hg rebase.
This is a behavior change because pull --rebase with a dirty working directory
will now abort after performing the pull rather than before.
