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:
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:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary:
This makes tests closer to production setup and removes a bunch of "saved
backup bundle to ..." messages.
With D9236657, this should not hurt server-side performance.
Unfortunately a lot tests cannot be migrated easily, mostly because revision
numbers are used. They are left with a TODO.
Reviewed By: DurhamG
Differential Revision: D9237694
fbshipit-source-id: c993fce18f07aba09f6d70964e248af8d501575a
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:
mq is already somehow problematic at D8907646. Without bandwidth supporting
it, let's remove it.
Alternative to mq would be rebase, shelve, unshelve, histedit.
Maintain "--config extensions.mq=" compatibility by marking it builtin so hg4idea
won't break by this change.
Reviewed By: phillco
Differential Revision: D9039741
fbshipit-source-id: a3a1e48a2a982ff8e8b6a6ce659c906a4e2b2b36
Summary: Also change the internal API so it no longer accepts the "heads" argument.
Reviewed By: ryanmce
Differential Revision: D6745865
fbshipit-source-id: 368742be49b192f7630421003552d0a10eb0b76d
# 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)
This config has been around for about 2 years now. So, it can be
assumed to be stable. Therefore, I am removing the config. This also makes the
test 'test-histedit-base.t' compatible with chg.
Test Plan:
- Ran the test 'test-histedit-base.t' with and without '--chg' option.
- Ran all the other tests without '--chg' option.
- Checked the output of 'hg help histedit'.
Differential Revision: https://phab.mercurial-scm.org/D942
If someone changes "pick" to "roll" or "fold" for the first
changeset in a histedit rule Mercurial could remove a wrong
changeset if the phase is non-public.
roll or fold for the first changeset should be invalid.
This change adjusts and documents the new behaviour of 'roll'. It now fits nicely
with the behaviour of 'commit --amend' and the 'edit' action, by discarding the
date as well as the commit message of the second commit. Previously it used the
later date, like 'fold', but this often wasn't desirable, for example, in the
common use case of using 'roll' to add forgotten changes to a changeset
(because 'hg add' was previously forgotten or not all changes were identified
while using 'hg record').
Selecting editing commits, rewording commit messages, and
selecting commits are key actions, we will prefer them more
generally in a future commit, this pulls them ahead before
that to make the diffs easier to read.
The remaining commands are left alphabetically sorted
Users may spend a lot of effort writing histedit rules,
getting an abort without being told they can recover their work
is very frustrating.
Avoid that by telling them where to find their work.
Before this patch, making a commit on a local repo could move a bookmark and
both operations would not be grouped as one transaction. This patch makes both
operations part of one transaction. This is necessary to switch to the new api
to save bookmarks repo._bookmarks.recordchange if we don't want to change the
current behavior of rollback.
Dirstate change happening after the commit is done is now part of the
transaction mentioned above. This leads to a change in the expected output of
several tests.
The change to test-fncache happens because both lock are now released in the
same finally clause. The lock release is made explicitly buggy in this test.
Previously releasing lock would crash triggering release of wlock that crashes
too. Now lock release crash does not directly result in the release of wlock.
Instead wlock is released at garbage collection time and the error raised at
that time "confuses" python.
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
This is suboptimal as the user still has to explicitly cancel the
histedit afterwards, but it prevents the immediate problem.
histedit should probably implicitly do 'hg histedit --abort' if a
util.Abort is raised internally.
Durham and I agree that it's a bug you can fold into a change that's
not listed in the histedited set, so we'll follow this up with a
change that prevents folds as the first edit step.
The phase of the pending commit depends on the parent of the working directory
and on the phases.newcommit configuration.
First, this information rather depend on the commit line which describe the
pending commit.
Then, we only want to be advertised when the pending phase is going to be higher
than the default new commit phase.
So the format will change from
$ hg summary
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge)
update: (current)
phases: 1 secret (secret)
to
parent: 2:ab91dfabc5ad
foo
parent: 3:24f1031ad244 tip
bar
branch: default
commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret)
update: (current)
phases: 1 secret
The number of draft and secret changesets are currently not summarized.
This is an important information because the number of drafts give some rough
idea of the number of outgoing changesets in typical workflows, without needing
to probe a remote repository. And a non-zero number of secrets means that
those changeset will not be pushed.
If the repository is "dirty" - some draft or secret changesets exists - then
summary will display a line like:
phases: X draft, Y secret (public)
The phase in parenthesis corresponds to the highest phase of the parents of
the working directory, i.e. the current phase.
By default, the line is not printed if the repository is "clean" - all
changesets are public - but if verbose is activated, it will display:
phases: (public)
On the other hand, nothing will be printed if quiet is in action.
A few tests have been added in test-phases.t to cover the -v and -q cases.
test-histedit-edit was broken because it relied on the HGEDITOR script being
executable. Instead, lets just execute 'sh' and pass it the script to run. This
seems to be the pattern followed in other tests.
--edit-plan was completely broken from the command line because it used an old
api that was not updated (it would crash with a stack trace). Let's update it
and add tests to catch this.
It's possible for the user to delete some of the commits they started with
during a histedit, and aborting the histedit doesn't bring them back. Let's
store a backup bundle so we can always recover the stack of commits from before
they began.
We were trying to prevent strips of important nodes during histedit,
but the check was actually comparing the short hashes in the rules to
the exact value the user typed in, so it only ever worked if the user
typed a 12 character hash.
This was accidentally fixed by other work, but given that it's been
broken in the past, I'd like to have a test defending us against
regressions in this area, especially as we add more functionality to
histedit.
During histedit we don't want user to do any operation resulting in
stripping nodes needed to continue history editing. This patch
wraps the strip function to detect such situations.
Previously, a backup bundle could overwrite an existing bundle and cause user
data loss. For instance, if you have A<-B<-C and strip B, it produces backup
bundle B-backup.hg. If you then hg pull -r B B-backup.hg and strip it again, it
overwrites the existing B-backup.hg and C is lost.
The fix is to add a hash of all the nodes inside that bundle to the filename.
Fixed up existing tests and added a new test in test-strip.t
This omits (redundant) adding "\n' to "message", because:
- empty line is inserted by "commitforceeditor", if editor is invoked
- tail white-spaces are stripped at storing into chaneglog, otherwise
This patch also enhances "test-histedit-edit.t", because "hg histedit"
hasn't been explicitly tested around editor invocation and
"--continue" option.
Before this patch, "hg histedit" for "message" uses "ui.edit()" for
commit message editing.
It shows original commit message, but not detail about the target
revision: status of each modified/added/removed files, for example.
This patch uses the editor gotten by "getcommiteditor()" instead of
"ui.edit()" for "message"
In "test-histedit-edit.t", this patch omits "fixbundle" invocation,
because it prevents from confirming the "HG: added f" line in commit
message by filtering " added " lines.
Omiting "fixbundle" invocation causes that the exit code of "hg
histedit" appears as one of command line: in this case, "hg histedit"
is aborted by (expected) exception raising.
Before this patch, "message" action of "hg histedit" uses "ui.edit()"
explicitly to get commit message edited manually.
This requires explicit "localrepository.savecommitmessage()"
invocation to save edited commit message into ".hg/last-message.txt",
because unexpected exception raising may abort command execution
before saving it in "localrepository.commit()".
This patch uses "editor" argument of "localrepository.commit()"
instead of explicit "ui.edit()" invocation for "message" action of "hg
histedit"
"localrepository.commit()" will invoke "editor()" function newly added
in this patch, and save edited commit message into ".hg/last-message.txt"
automatically.
Before this patch, manually edited commit message for "message"
command in histedit-ing is not saved into ".hg/last-message.txt" until
it is saved by "localrepository.savecommitmessage()" in
"localrepository.commit()".
This may lose such commit message, if unexpected exception is raised.
This patch saves manually edited commit message for "message" comand
in histedit-ing into ".hg/last-message.txt" just after user editing.
This is the simplest implementation to fix on stable. Editing and
saving commit message should be centralized into the framework of
"localrepository.commit()" with "editor" argument in the future.
This patch uses repository wrapping class for exception raising before
saving commit message in "localrepository.commit()" easily and
certainly, because such exception requires corner case condition.
The tests contain a couple corner cases where workarounds are now
required. Strictly speaking, these are behavior regressions, but of an
extremely obscure and marginal sort. Commits or updates in the middle
of a histedit would have almost always been fairly serious user error.
This is simpler than temporary file version. There some minor test
changes since commit messages are no longer modifed. There is still
some tests using --commands with a real file.
