By including the working directory revision at the start of rebase in
the repo._rebaseset, we make sure it's not hidden when we update back
to it at the end of the rebase.
This feels like abusing the set a bit given its name (_rebaseset), but
I couldn't think of another name that's clearly better.
There are two reasons that rebase should be done this way:
1. This would make rebasing faster because it would minimize the total
number of files to be checked out in the process, as it don't need
to switch back and forth between branches.
2. It makes resolving conflicts easier as user has a better context.
This commit changes the behavior in "Test multiple root handling" of
test-rebase-obsolete.t. It is an expected change which reflects the new
behavior that commits in a branch are grouped together when rebased.
Before this patch, rebase --continue would crash when trying to resume a rebase
of obsolete revisions whose successors were in the destination.
This patch adds logic to recompute the mapping when rebase is resumed. This
patch also adds a test that showcased the crash before the code change.
Consider the following use case. User has a set of commits he wants to rebase
onto some destination. Some of the commits in the set are already rebased
and their new versions are now among the ancestors of destination. Traditional
rebase behavior would make the rebase and effectively try to apply older
versions of these commits on top of newer versions, like this:
a` --> b --> a`
(where both 'a`' and 'a``' are rebased versions of 'a')
This is not desired since 'b' might have made changes to 'a`' which can now
result in merge conflicts. We can avoid these merge conflicts since we know
that 'a``' is an older version of 'a`', so we don't even need to put it on top
of 'b'. Rebaseskipobsolete allows us to do exactly that.
Another undesired effect of a pure rebase is that now 'a`' and 'a``' are both
successors to 'a' which is a divergence. We don't want that and not rebasing
'a' the second time allows to avoid it.
This was not enabled by default initially because we wanted to have some more
experience with it. After months of painless usages in multiple places, we are
confident enough to turn it on my default.
Changeset 9a4b77db854b introduced a guard against case where obsolete changesets
are included in the rebase in a way this will result in divergence (because
rebase create new successors for changeset which already have successors). In
the same go a 'rebase.allowdivergence' option was introduced to control that
behavior.
We rename this config option to 'experimental.allowdivergence' for multiple
reasons:
* First this behavior is attached to changeset evolution, a feature still
experimental.
* Second, there was no 'rebase' section in config before we introduced this
option. I would like to avoid proliferation of micro config section and
therefore would like to avoid the creation of this new section just for an
experimental feature.
* Third, this guard (warning the user about a history rewriting operation that
will create divergence) will very likely be generalised to all history
rewriting operations, making this not rebase specific.
* Finally, because this will likely be a general guard present a bit everywhere
in the UI we'll likely end up with something better than a config option to
control this behavior, so having the current config option living in
experimental will allow us make it disappear in the future.
So we banish this config option back to the experimental section where it
belongs, killing the newly born 'rebase' config section in the process.
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.
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)
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
Preserving the 'source' attribute of grafts started with 091a7dd3c7d0, which
predates the introduction of 'intermediate-source' in 7fbf0ef28408 by a year and
a half. It looks like not preserving this was an oversight.
On a related note, notice how the source value of 32af76 is no longer visible in
the graph above this test. Is it reasonable to import the sha1 translation from
evolve.py:relocate() into scmutil or similar, and use that to fixup these
attributes as well as the commit message? (I realize that evolve is still
experimental, but I don't see a way to do this from the evolve extension.)
--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.
As obsolescence markers can contains unknown nodes and 'allsuccessors' returns
them, we have to protect again that when looking for successors of the rebase
set in the destination.
Test have been expanded to catch that.
This patch avoids unnecessary conflicts to resolve during rebase for the users
of changeset evolution.
This patch modifies rebase to skip obsolete commits if they are being rebased on
their successors.
It introduces a new rebase state 'revprecursor' 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:
not rebasing 14:9ad579b4a5de "I", already in destination as 17:fc37a630c901 "K"
Before this changeset rebase was getting very confused if any revision in the
rebase set became hidden. This was fairly easy to achieve if a rebased revision
was made visible by the working copy location. The rebase process would update
somewhere else and the revision would become hidden.
To work around this issue, we ensure rebased revisions remain visible for the
whole process.
This is a simple change suitable for stable. More subtle usage of unfiltered
repository in rebase may solve this issue more cleanly.
Show status messages while rebasing, similar to what graft do:
rebasing 12:2647734878ef "fork" (tip)
This gives more context for the user when resolving conflicts.
Show status messages with first line of commit description and names, like
grafting 12:2647734878ef "fork" (tip)
This gives more context for the user when resolving conflicts.
The obsolete._enabled flag has become a config option. This updates all but one
of the tests to use the minimal number of flags necessary for them to pass. For
most tests this is just 'createmarkers', for a couple tests it's
'allowunstable', and for even fewer it's 'exchange'.
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)
In the way to solving issue3813 we'll preserve the working directory parent
after the rebase. Multiple rebases test expect the working directory parent to
be tip after rebase. We patches them before the actual change to prevent
confusion.
With rebase taking multiple roots it is possible to have revision in the "rebase
domain" not rebased themself. We do not want rebased revision above them to be
detached. We want such revision to be rebased on the nearest rebased ancestors.
This allows to preserve the topology of the rebase set as much a possible
To achieve this we introduce a new state `revignored` which informs
`defineparents` of the situation.
The test in `test-rebase-obsolete.t` was actually wrote and his now fixed.
When rebase results in an empty a changeset it is "skipped" and no related
changeset is created at all. When we added obsolescence support to rebase (in
cee0a253a56c) it seemed a good idea to use its parent successor as the
successors for such dropped changesets. (see old version of the altered test).
This option was chosen because it seems a good way to hint about were the
dropped changeset "intended" to be. Such hint would have been used by automatic
evolution mechanism to rebase potential unstable children.
However, field testing of this version are not conclusive. It very often leads
to the creation of (totally unfounded) evolution divergence. This changeset
changes this behavior and mark skipped changesets as pruned (obsolete without
successors). This prevents the issue and seems semantically better probably a
win for obsolescence reading tool.
See example bellow for details:
User Babar has five changesets of interest:
- O, its current base of development.
- U, the new upstream
- A and C, some development changesets
- B another development changeset independent from A
O - A - B - C
\
U
Babar decides that B is more critical than the A and C and rebase it first
$ hg rebase --rev B --dest U
B is now obsolete (in lower case bellow). Rebase result, B', is its
successors.(note, C is unstable)
O - A - b - C
\
U - B'
Babar is now done with B', and want to rebase the rest of its history:
$ hg rebase --source A --dest B'
hg rebase process A, B and C. B is skipped as all its changes are already contained
in B'.
O - U - B' - A' - C'
Babar have the expected result graph wise, obsolescence marker are as follow:
B -> B' (from first rebase)
A -> A' (from second rebase)
C -> C' (from second rebase)
B -> ?? (from second rebase)
Before this changeset, the last marker is `B -> A'`. This cause two issues:
- This is semantically wrong. B have nothing to do with A'
- B has now two successors sets: (B',) and (A',). We detect a divergent
rewriting. The B' and A' are reported as "divergent" to Babar, confusion
ensues. In addition such divergent situation (divergent changeset are children
to each other) is tricky to solve.
With this changeset the last marker is `B -> ø`:
- This is semantically better.
- B has a single successors set (B',)
This scenario is added to the tests suite.
We have all the necessary mechanism to rebase a set with multiple roots, we only
needed a proper handling of this case we preparing and concluding the rebase.
This changeset des that.
Rebase set with multiple root allows some awesome usage of rebase like:
- rebase all your draft on lastest upstream
hg rebase --dest @ --rev 'draft()'
- exclusion of specific changeset during rebase
hg rebase --rev '42:: - author(Babar)'
- rebase a set of revision were multiple roots are later merged
hg rebase --rev '(18+42)::'
The `ui.prevent-unstable` option never made it into core. It always behaves
this way when obsolescence feature is enabled.
See changesets caaf2a66c719, f111507ae88a and 51dfebaadebc for details.
Obsolescence markers can represent this situation just fine. Rebased
revisions are marked as precursors of the ones create by
rebase. Unrebased descendants becomes "unstable".
If obsolescence is not enabled we keep the current behavior of
aborting. This new behavior only applies when obsolete is
enabled and is subject to future discussion and changes.
Here, we exclude hidden changesets from a rebase operation. If we
don't, a rewritten version of the hidden changesets will be created
by rebase. Those rewritten versions won't be hidden and will likely
conflict with other rewriting or revive pruned changeset. Moreover,
rewriting hidden revisions will surprise the user.
This change would not be necessary if changelog filtering were
already in core. But it's fairly cheap and helps to increase the
test-suite for such filtering.
Once changelog level filtering is added, hidden changes will be
automatically excluded or included according to the global --hidden
flags. Plain ignoring them is good enough for now.
In collapse mode, that content of state is not suitable to compute obsolescence
markers. We explicitly pass the resulting revision instead and use it as the
successors for all elements of the rebased set.
When obsolescence feature is enabled we now create markers from the rebased
set to the resulting set instead of stripping. The "state" mapping built by
rebase holds all necessary data.
Changesets "deleted" by the rebase are marked "succeeded" by the changeset they
would be rebased one. That the best guess of "successors" we have. Getting a
successors as meaningful as possible is important for automatic resolution of
obsolescence troubles. In other word, emptied changeset will looks collapsed
with their former parents. (see "empty changeset" section of the test if you are
still confused)
