Summary:
Now that all our repos are treemanifest, let's enable the extension by
default in tests. Once we're certain no one needs it in production we'll also
make it the default in core Mercurial.
This diff includes a minor fix in treemanifest to be aware of always-enabled
extensions. It won't matter until we actually add treemanifest to the list of
default enabled extensions, but I caught this while testing things.
Reviewed By: ikostia
Differential Revision: D15030253
fbshipit-source-id: d8361f915928b6ad90665e6ed330c1df5c8d8d86
Summary:
With treemanifest we no longer have manifest rev numbers, so let's drop
them from the templates. This let's us convert a few more tests to treeonly.
In theory automation may parse this, but I kinda doubt anyone parses the
manifest node from this.
Reviewed By: xavierd
Differential Revision: D15296141
fbshipit-source-id: a4d2194bd9604867cd9958509bcd2e6513a72494
Summary:
The postincoming checks prints out advice of the following forms:
* `(run 'hg heads' to see heads)`
* `(run 'hg heads' to see heads, 'hg merge' to merge)`
* `(run 'hg heads .' to see heads, 'hg merge' to merge)`
* `(run 'hg update' to get a working copy)`
This advice is no longer useful, so remove it.
Reviewed By: DurhamG, farnz
Differential Revision: D15317185
fbshipit-source-id: 50ba576406c96715fa058399da53462be9b7a3bf
Summary:
Move the strip extension to core. Rename the command to `hg debugstrip` as it
is not intended for use by users. Users should use `hg hide` instead.
Reviewed By: quark-zju
Differential Revision: D14185822
fbshipit-source-id: ef096488cb94b72a7bb79f5bf153c064e0555b34
Summary:
When you get an error, let's print the number of conflicts in each file. This will give the user some sense of how much work they have to do.
The code change is entirely in `filemerge.py`, and `tests/test-merge-conflict-count.t` adds a new test.
Reviewed By: quark-zju
Differential Revision: D9815243
fbshipit-source-id: 1b73a1db293902ac7242997a7d6ae09478344068
Summary:
I noticed `hg summary` takes 32 seconds running in my local repo. Profiling
shows 30 seconds spent on `changelog.findmissing`. We don't use branches and
heavily patched other places to get rid of branch heads logic. So let's remove
them from `hg summary` too.
Reviewed By: phillco
Differential Revision: D9477205
fbshipit-source-id: 17b07190b6dcc96bc3a5f3c2b5ff4aa1366f4904
Summary:
Reviving commits is an essential feature. So move it to core.
Most test changes are caused by the auto-date-bump behavior, which is needed to
revive commits automatically.
Note the existing code is not fully ready for the change. For example,
`precursors.get(node)`, `successors.get(node)` do not filter out markers that
are suppressed. For example, some code paths treat node as obsoleted if
`precursors.get(node)` is non-empty. That's no longer true. markbt's
planned visibility change might clean up this area a bit.
Regarding on tests, most changes are because of the "auto bump date" feature.
The graphlog change in `test-obsmarker-template.t` is because it creates a
cycle, which behaves differently in the new code. Half of obsmarker exchange
tests break. Given the fact that we do not use and will probably rewrite the
exchange algorithm, related tests are deleted, including
`test-obsolete-distributed.t`.
Reviewed By: DurhamG
Differential Revision: D9236661
fbshipit-source-id: 85b983f8bd46dece908c05f56bea2abbc8ffbaf6
Summary: They help making tests easier to write.
Reviewed By: phillco
Differential Revision: D7121645
fbshipit-source-id: 9c7181d45c4e28155eb68f355cf1c4cfc077d191
Summary:
Since we have `debugbuilddag` as a builtin command, and `drawdag` is
pretty useful for writing clean test cases. Let's inline it. This would
simplify many tests since `drawdag=..." is no longer needed.
Reviewed By: DurhamG
Differential Revision: D6827925
fbshipit-source-id: b749f57fd5c55b2cb000dd2da2c2f9bc2386a519
Summary:
The helper could be used in individual tests to enable chg if chg exists.
This allows us to have more precise control on what tests to use chg instead
of using a global flag in run-tests.py.
This makes certain tests containing many hg commands much faster. For example,
`test-revset.t` took 99 seconds before:
% ./run-tests.py test-revset.t --time
.
# Ran 1 tests, 0 skipped, 0 failed.
# Producing time report
start end cuser csys real Test
0.000 99.990 86.410 12.000 99.990 test-revset.t
And 10 seconds after:
% ./run-tests.py test-revset.t --time
.
# Ran 1 tests, 0 skipped, 0 failed.
# Producing time report
start end cuser csys real Test
0.000 10.080 0.380 0.130 10.080 test-revset.t
Also enable it for some other tests. Note the whitelist is not complete. We
probably want to whitelist more tests in the future.
The feature could be opted out by deleting `contrib/chg/chg`.
Reviewed By: phillco
Differential Revision: D6767036
fbshipit-source-id: 8220cf408aa198d5d8e2ca5127ca60e2070d3444
Summary: Also change the internal API so it no longer accepts the "heads" argument.
Reviewed By: ryanmce
Differential Revision: D6745865
fbshipit-source-id: 368742be49b192f7630421003552d0a10eb0b76d
Summary: This removes the effectflag logic from both core and perftweaks.
Reviewed By: ryanmce
Differential Revision: D6745769
fbshipit-source-id: 55ed1676e7117bca358471c256805ded7bc83f3c
# skip-blame because this was mechanically rewritten the following script. I
ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t
ones appear to be, and they run without addition failures on both Windows and
Linux.
import argparse
import os
import re
ap = argparse.ArgumentParser()
ap.add_argument('path', nargs='+')
opts = ap.parse_args()
globre = re.compile(r'^(.*) \(glob\)(.*)$')
for p in opts.path:
tmp = p + '.tmp'
with open(p, 'rb') as src, open(tmp, 'wb') as dst:
for line in src:
m = globre.match(line)
if not m or '$LOCALIP' in line or '*' in line:
dst.write(line)
continue
if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
dst.write(line)
continue
dst.write(m.group(1) + m.group(2) + '\n')
os.unlink(p)
os.rename(tmp, p)
.. feature::
Let 'hg rebase' avoid content-divergence by skipping obsolete
changesets (and their descendants) when they are present in the rebase
set along with one of their successors but none of their successors is
in destination.
In the following example, when trying to rebase 3:: onto 2, the rebase
will abort with "this rebase will cause divergence from: 4":
o 7 f
|
| o 6 e
| |
| o 5 d'
| |
x | 4 d (rewritten as 5)
|/
o 3 c
|
| o 2 x
| |
o | 1 b
|/
o 0 a
By excluding obsolete changesets without a successor in destination (4
in the example above) and their descendants, we make rebase work in this
case, thus giving:
o 11 e
|
o 10 d'
|
o 9 c
|
o 8 b
|
| o 7 f
| |
| | x 6 e (rewritten using rebase as 11)
| | |
| | x 5 d' (rewritten using rebase as 10)
| | |
| x | 4 d
| |/
| x 3 c (rewritten using rebase as 9)
| |
o | 2 x
| |
| x 1 b (rewritten using rebase as 8)
|/
o 0 a
where branch 4:: is left behind while branch 5:: is rebased as expected.
The rationale is that users may not be interested in rebasing orphan
changesets when specifying a rebase set that include them but would
still want "stable" ones to be rebased. Currently, the user is suggested
to allow divergence (but probably does not want it) or they must specify
a rebase set excluding problematic changesets (which might be a bit
cumbersome). The approach proposed here corresponds to "Option 2" in
https://www.mercurial-scm.org/wiki/CEDRebase.
We extend _computeobsoletenotrebased() so that it also return a set of
obsolete changesets in rebase set without a successor in destination but
with at least one successor in rebase set. This
'obsoletewithoutsuccessorindestination' is then stored as an attribute
of rebaseruntime and used in _performrebasesubset() to:
* filter out descendants of these changesets from the revisions to
rebase;
* issue a message about these revisions being skipped.
This only occurs if 'evolution.allowdivergence' option is off and
'rebaseskipobsolete' is on.
Grouping all evolution related-config under the experimental.evolution
namespace would helps the future migration outside [experimental].
Differential Revision: https://phab.mercurial-scm.org/D1155
We want to get rid of stabilization.* configuration, back out to the old
configuration 'evolution.track-operation'.
Differential Revision: https://phab.mercurial-scm.org/D1153
Extract 'experimental.evolution' = allowunstable as
'experimental.evolution.allowunstable'.
We keep the new option in the 'experimental.evolution' namespace in order to
stay coherent with other options ('experimental.evolution.bundle-obsmarker'
and 'experimental.evolution.track-operation') ease the renaming as possibly
'evolution.allowunstable'.
Differential Revision: https://phab.mercurial-scm.org/D1150
Extract 'experimental.evolution' = createmarkers as
'experimental.evolution.createmarkers'.
We keep the new option in the 'experimental.evolution' namespace in order to
stay coherent with other options ('experimental.evolution.bundle-obsmarker'
and 'experimental.evolution.track-operation') ease the renaming as possibly
'evolution.createmarkers'.
Differential Revision: https://phab.mercurial-scm.org/D1149
We replace 'experimental.stabilization=all' by 'experimental.evolution=true'
as we will extract individual config in their own config in later patches.
Differential Revision: https://phab.mercurial-scm.org/D1148
Upon pull or unbundle, we display a message with the range of new revisions
fetched. This revision range could readily be used after a pull to look out
what's new with 'hg log'. The algorithm takes care of filtering "obsolete"
revisions that might be present in transaction's "changes" but should not be
displayed to the end user.
This makes use of the generic method of listing bookmarks and tags, so
other extensions that add other namespaces will get their names added
too.
This does mean that bookmarks will come before tags, just like we
apparently decided to order them in the "hg log" output. It doesn't
seem like people would be parsing the rebase output anyway. We also
did 9461eb4ff93e (rebase: use _ctxdesc in one more place, 2017-08-29)
recently, so now seems like a good time.
Differential Revision: https://phab.mercurial-scm.org/D741
We added support for including the operation responsible for creating
the obsmarker in 44ba6434eaf4 (obsolete: add operation metadata to
rebase/amend/histedit obsmarkers, 2017-05-09). However, soon
thereafter, in 819cf35e629a (obsmarker: add an experimental flag
controlling "operation" recording, 2017-05-20), it was hidden behind a
config that was off by default. It seems unlikely that people will
manually turn it on, and obsmarkers/evolution as a whole is still
experimental anyway, so let's turn on the tracking by default.
Differential Revision: https://phab.mercurial-scm.org/D722
Before this patch, `rebase --abort` may fail to do the cleanup:
$ hg rebase --abort
rebase aborted (no revision is removed, only broken state is cleared)
The added test case makes sure `--abort` works in this case.
Differential Revision: https://phab.mercurial-scm.org/D643
There was an extra commit made during the amend operation to track the
changes to the working copy. However, this logic was written a long time back
and newer API's make this extra commit redundant. Therefore, I am removing the
extra commit. After this change, I noticed that
- Execution time of the cmdutil.amend improved by over 40%.
- Execution time of "hg commit --amend" improved by over 20%.
Test Plan:
I ensured that the all the hg tests passed after the change. I had
to fix a few tests which were aware of the extra commit made during the amend.
Differential Revision: https://phab.mercurial-scm.org/D636
Previously, obsoleted revs with successors in destination are completely
ignored. That caused some inconvenience when working copy is obsoleted. Most
commands avoid working copy being obsoleted, but `hg pull` is an exception.
This patch makes rebase able to move bookmarks or working parent for those
obsoleted revs. It does so by keeping the obsoleted revs in `state` and
marking them as "skipped, rebased to desired destination" during run-time.
This reverts part of the behavior change of 80d53a39fbcc and D24.
Differential Revision: https://phab.mercurial-scm.org/D527
Previously, when there are 2 merge base candidates, we choose p1 blindly,
which may make the merge result to have "unwanted content". This patch makes
rebase smarter - choose a merge base that does not have "unwanted revs" if
possible. Since we don't really have a good solution when there are
"unwanted revs", abort in that case.
Differential Revision: https://phab.mercurial-scm.org/D340
These states will be removed to make the code cleaner and more robust.
Remove their messages first to make review easier.
Differential Revision: https://phab.mercurial-scm.org/D25
Those states are no longer necessary for rebase to function properly. Remove
them to make the code cleaner.
Marked as BC because in a corner case where working parent is obsoleted, and
is skipped for rebase, we no longer move working parent after rebase
completes. That is better since if working parent is obsoleted, it should be
the user moving working parent back there (after a rebase) explicitly, in
that case, we shouldn't move working parent again.
Differential Revision: https://phab.mercurial-scm.org/D24
A later patch will clean up those states. This patch moves the messages
earlier.
Marked as BC since the order of message has changed.
Differential Revision: https://phab.mercurial-scm.org/D23
The old error message "cannot use revision REV as base, result would have 3
parents" is confusing - why use REV as base? why add a new parent?.
This patch changes it to "cannot move parent", which seems better.
Differential Revision: https://phab.mercurial-scm.org/D342
"defineparents" is the core algorithm of rebase. The old code has too many
tech debts (like outdated comments, confusing assertions, etc) and is very
error-prone to be improved. This patch rewrites "defineparents" to make the
code easier to reason about, and solve a bunch of issues, including:
- Assertion error: no base found (demonstrated by D212, issue5578)
- Asymmetric result (demonstrated by D211, "F with one parent")
- Wrong new parent (demonstrated by D262, "C':A'A'")
- "revlog index out of range" (demonstrated by D262, issue5630)
- "nothing to merge" (demonstrated by D262)
As a side effect, merge base decision has been made more solid - rebase now
prints out explicitly what could go wrong when it cannot find a unique
suitable merge base.
.. fix:: Issue 5578, Issue 5630
Core rebase algorithm has been rewritten to be more robust.
Differential Revision: https://phab.mercurial-scm.org/D21
evolution* config has been rewritten in stabilization* in the previous patch,
update tests file to use the new names.
Differential Revision: https://phab.mercurial-scm.org/D249
Rename divergent to content-divergent in all external user-facing output. Only
update user-facing output for the moment, variables names, templates keyword
and potentially configuration would be done in later series.
The renaming is done according to
https://www.mercurial-scm.org/wiki/CEDVocabulary.
Differential Revision: https://phab.mercurial-scm.org/D215
As the test case shows, when "hg rebase -d G -r 'B + D + F'" is run on
the following graph, we crash with traceback. It's reasonable to fail
because we can not easily produce a correct rebased F. The problem is
what diff to apply to either the rebased B or the rebased D. We could
potentially produce the result by e.g. applying the (F-D) diff to the
rebased B and then applying the reverse (E-D) diff on top, but that
could result in merge conflicts in each of those steps, which we don't
have a way of dealing with. So for now, let's just add a test case to
demonstrate that we crash (i.e. the AssertionError is clearly
incorrect since the user can run into it).
F
/|
C E
| |
B D G
\|/
A
Differential Revision: https://phab.mercurial-scm.org/D212
The fix in c97497e78a9b (rebase: handle successor targets (issue5198),
2016-04-11) only fixed the case where p2's successor was in the
destination, and only when the successor was exactly the destination
(i.e. not when the successor was an ancestor of it). This patch adds a
test case for when p1's successor is in the destination. It adds
another one for when the successor is an ancestor of the
destination. To do that simply, it also rewrites the test case using
drawdag.
Differential Revision: https://phab.mercurial-scm.org/D211
Rename unstable to orphan in all external user-facing output. Only update
user-facing output for the moment, variables names, templates keyword and
potentially configuration would be done in later series.
The renaming is done according to
https://www.mercurial-scm.org/wiki/CEDVocabulary.
Differential Revision: https://phab.mercurial-scm.org/D214
This patch migrates rebase to use scmutil.cleanupnodes API. It simplifies
the code and makes rebase code reusable inside a transaction.
This is a BC because the backup file is no longer strip-backup/*-backup.hg,
but strip-backup/*-rebase.hg. The latter looks more reasonable since the
directory name is "strip-backup" so there is no need to repeat "backup".
I think the backup file name change is probably fine as a BC, since we have
changed it before (2e51c9a7a08f) and didn't get complains. The end result
of this series will be a much more consistent and unified backup names:
command | old backup file suffix | new backup file suffix
-------------------------------------------------------------------
amend | amend-backup.hg | amend.hg
histedit | backup.hg (could be 2 files) | histedit.hg (single file)
rebase | backup.hg | rebase.hg
strip | backup.hg | backup.hg
(note: backup files are under .hg/strip-backup)
It also fixes issue5606 as a side effect because the new "delayedstrip" code
path will carefully examine nodes (safestriproots) to make sure orphaned
changesets won't get stripped by accident.
Some warning messages are changed to the new "warning: orphaned descendants
detected, not stripping HASHES", which provides more information about
exactly what changesets are left behind.
Another minor behavior change is when there is an obsoleted changeset with a
successor in the destination branch, bookmarks pointing to that obsoleted
changeset will not be moved. I have commented in test-rebase-obsolete.t
explaining why that is more desirable.
In the next patch, I'm gonna removing the global command aliases that force
the epoch date but some tests either fail or their output change after that.
Instead I'm copying the needed aliases in the test files that will otherwise
change.
Update test-rebase-obsolete.t because a revision hash is based on the epoch
date after a 'commit --amend' and the output will change after removing date
aliases.
Update test-subrepo-git.t as the git subrepo doesn't use traditional date
mechanisms. I'm not sure that updating the git subrepo to support default-date
make sense. Add the commit alias to the test in order for making it pass after
removing the date aliases globally.
It seems better to introduce the experiment behind a flag for now as there are
multiple concerns around the feature:
* Storing operation increase the size of obsolescence markers significantly
(+10-20%).
* It performs poorly when exchanging markers (cannot combine command names,
command name might be unknown remotely, etc)
By recording what operation created the obsmarker, we can show very intuitive
messages to the user in various UIs. For instance, log output could have
messages like "Amended as XXX" to show why a commit is old and has an 'x' on it.
@ ac28e3 durham
/ First commit
|
| o d4afe7 durham
| | Second commit
| |
| x 8e9a5d (Amended as ac28e3) durham
|/ First commit
|
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.