Summary:
Removes bundlev1 from the supported outgoing versions, but keeps a flag
around to force enable it if tests need it.
Reviewed By: quark-zju
Differential Revision: D7591176
fbshipit-source-id: 280cbbbe87848e3d6c9d448ce4f87c5eadeff720
Summary:
We want to deprecate the bundlev1 format, so let's start by adding a
develwarn. Later diffs will update the tests to not use v1, then remove v1 as a
supported outgoing bundle entirely.
Reviewed By: quark-zju
Differential Revision: D7591166
fbshipit-source-id: 143ad029bfe4d141f91d6d5077342dfa44ad2944
Summary:
Let's switch to xdiff for its better diff quality and performance!
The test changes demonstrate xdiff's better diff quality.
Reviewed By: ryanmce
Differential Revision: D7135206
fbshipit-source-id: 1775df6fc0f763df074b4f52779835d6ef0f3a4e
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
# 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)
Automatic replacement seems better than trying to figure out a check-code rule.
I didn't bother looking to see why the error message and file name is reversed
in the annotate and histedit tests, based on Windows or not.
I originally had this as a list of tuples, conditional on the platform. But
there are a couple of 'No such file or directory' messages emitted by Mercurial
itself, so unconditional is required for stability. There are also several
variants of what I assume is 'connection refused' and 'unknown host' in
test-clone.t and test-clonebundles.t for Docker, FreeBSD jails, etc. Yes, these
are handled by (re) tags, but maybe it would be better to capture those strings
in order to avoid whack-a-mole in future tests. All of this points to using a
dictionary containing one or more strings-to-be-replaced values.
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
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.
When ui.origbackuppath is set, .orig files are stored outside of the working
copy, however they still have a .orig suffix appended to them. This can cause
unexpected conflicts, particularly when tracked files or directories have .orig
at the end.
This change removes the .orig suffix from files stored in an out-of-tree
origbackuppath.
Test Plan:
Update and run unit tests.
Differential Revision: https://phab.mercurial-scm.org/D679
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
morestatus extension in fbext use to show more context about the state of the
repo like the repository is in a unfinished merge state, or a rebase is going
on, or histedit is going on, listing the files which need to be resolved and
also suggesting ways to handle the situation.
This patch moves the extension directly to core by plugging it into the
--verbose flag of the status command. So now if you are in any unfinished state
and you do hg status -v, it will show you details and help related to the state.
The extension in fbext also shows context about unfinished update state
which is not ported to core as that plug in hooks to update command which need
to be tackled somewhat differently.
The following configuration will turn the behaviour on by default
[commands]
status.verbose = 1
You can also skip considering some states like bisect as follows:
[commands]
status.skipstates=bisect
This patch also adds test for the feature.
.. feature::
``hg status -v`` can now show unfinished state. For example, when in
an unfinished rebase state, ``hg status -v`` might show::
# The repository is in an unfinished *rebase* state.
# No unresolved merge conflicts.
# To continue: hg rebase --continue
# To abort: hg rebase --abort
Differential Revision: https://phab.mercurial-scm.org/D219
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.
Currently shelvestate uses line ordering to differentiate fields. This
makes it hard for extensions to wrap shelve, since if two alternative
versions of code add a new line, correct merging is going to be problematic.
simplekeyvaluefile was introduced fot this purpose specifically.
After this patch:
- shelve will always write a simplekeyvaluefile
- unshelve will check the first line of the file for a version, and if the
version is 1, will read it in a position-based way, if the version is 2,
will read it in a key-value way
As discussed with Yuya previously, this will be able to handle old-style
shelvedstate files, but old Mercurial versions will fail on the attempt to
read shelvedstate file of version 2 with a self-explanatory message:
'abort: this version of shelve is incompatible with the version used
in this repo'
This makes using shelve/unshelve more consistent because
shelving can be done using name option and unshelving as
well. Author of the idea of this improvement and solution is
joshgold.
This patch makes it possible to unshelve while having missing files
in your repo as long as shelved changes don't touch those missing files.
It also makes error message better otherwise.
Before this patch, there was a single way to see multiple shelves using
`--patch --list` which show all the shelves. Doing `--patch s1 s2` returns an
error. This patch allows to show multiple shelves using `--patch` and `--stat`.
Currently if our branch name contains '\' or starts with '.', shelve chooses
an illegal shelve name. This behaviour is not good as it itself is choosing
something which it won't accept further. We can raise errors if user passes
a name which is illegal.
After this patch, if '\' is contained in branch name or bookmark name, it will
be replaced by '_' while choosing a shelve name and if they starts with '.',
the first '.' is replaced by '_'.
We avoid '.' as the first letter of shelve name so that we don't create hidden
file. We also avoid slashes in name so that we don't form a new directory
We are using 'name + ".patch"' pattern throughout the shelve code to
identify the existence of a shelve with a particular name. In two
cases however we use 'name + ".hg"' instead. This commit makes
'patch' be used in all places and "emphasizes" it by moving
'patch' to live in a constant. Also, this allows to extract file
name without extension like this:
f[:-(1 + len(patchextension))]
instead of:
f[:-6]
which is good IMO.
This is a first patch from this initial "obsshelve" series. This
series does not include tests, although locally I have all of
test-shelve.t ported to test obs-shelve as well. I will send tests
later as a separate series.
The ability to negate any boolean flags itself is great, but I think we are not
ready to expose the help side of it yet.
First, while there exist a handful of such flags whose default value can be
changed (eg: git diff, patchwork confirmation), there is only a few of them. The
users who benefit the most from this change are alias users and large
installation that can deploy extension to change behavior (eg: facebook
tweakdefault). So the majority of user who will be affected by a large change
to command help that is not yet relevant to them. (I expect this to become
relevant when ui.progressive start to exists).
Below is an example of the impact of the new help on 'hg help diff':
-r --rev REV [+] revision
-c --change REV change made by revision
-a --[no-]text treat all files as text
-g --[no-]git use git extended diff format
--[no-]nodates omit dates from diff headers
--[no-]noprefix omit a/ and b/ prefixes from filenames
-p --[no-]show-function show which function each change is in
--[no-]reverse produce a diff that undoes the changes
-w --[no-]ignore-all-space ignore white space when comparing lines
-b --[no-]ignore-space-change ignore changes in the amount of white space
-B --[no-]ignore-blank-lines ignore changes whose lines are all blank
-U --unified NUM number of lines of context to show
--[no-]stat output diffstat-style summary of changes
--root DIR produce diffs relative to subdirectory
-I --include PATTERN [+] include names matching the given patterns
-X --exclude PATTERN [+] exclude names matching the given patterns
-S --[no-]subrepos recurse into subrepositories
Another issue with the current state of help, the default value for the
flag is not conveyed to the user. For example in the 'backout' help, there is
no real distinction between "--[no-]backup" (default to True) and "--[no-]keep"
(default) to False:
--[no-]backup no backups
--[no-]keep do not modify working directory during strip
In addition, I've discussed with Augie Fackler and the last batch of the work on
this have burned him out quite some. Therefore he is not intending to perform
any more work on this topic. Quoting him, he would rather see the help part
backed out than spending more time on it.
I do not think we are ready to expose this to users in 4.0 (freeze in a week),
especially because we cannot expect quick improvement on these aspect as this
topic no longer have an owner. We should be able to reintroduce that change in
the future when someone get back on it and the main issues are solves:
* Introduction of ui.progressive makes it relevant for a majority of user,
* Current default value are efficiently conveyed to the user.
(In addition, the excerpt from diff help show that we still have some issue with
some negative option like '--nodates' so further improvement are probably
welcome there.)
Currently if user runs 'hg unshelve --keep' and merge conflicts
occur, the information about --keep provided by user is lost and
shelf is deleted after 'hg unshelve --continue'. This is obviously
not desired, so this patch fixes it.
The way default marker template was defined before this patch,
the spacing before dash in conflict markes was dependent on
whether changeset is a tip one or not. This is a relevant part
of template:
'{ifeq(tags, "tip", "", "{tags} "}'
If revision is a tip revision with no other tags, this would
resolve to an empty string, but for revisions which are not tip
and don't have any other tags, this would resolve to a single
space string. In the end this causes weirdnesses like the ones
you can see in the affected tests.
This is a not a big deal, but double spacing may be visually
less pleasant.
Please note that test changes where commit hashes change are
the result of marking files as resolved without removing markers.
That is, help gets tweaked thus:
global options ([+] can be repeated):
-v --[no-]verbose enable additional output
Other proposals have included:
global options ([+] can be repeated, options marked [?] are boolean flags):
-v --verbose[?] enable additional output
and
global options ([+] can be repeated, options marked [^] are boolean flags):
-v --verbose[^] enable additional output
which avoid the unfortunate visual noise in this patch. In this
version's favor, it's consistent with what I'm used to seeing in man
pages and similar documentation venues.
The bundle2 changegroup part has an advisory param saying how many
changesets are in the part. Before this patch, we were setting
this part when generating bundle2 parts via the wire protocol but
not when generating local bundle2 files.
A side effect of not setting the changeset count part is that progress
bars don't work when applying changesets. As the tests show, this
impacted clone bundles, shelve, backup bundles, `hg unbundle`, and
anything touching bundle2 files.
This patch adds a backdoor to allow us to pass state from
changegroup generation into the unbundler. We store the number
of changesets in the changegroup in this state and use it to
populate the aforementioned advisory part parameter when generating
the bundle2 bundle.
I concede that I'm not thrilled by how state is being passed in
changegroup.py (it feels a bit hacky). I would love to overhaul the
rather confusing set of functions in changegroup.py with something that
passes rich objects around instead of e.g. low-level generators.
However, given the code freeze for 3.9 is imminent, I'd rather not
undertake this endeavor right now. This feels like the easiest way
to get the parameter added to the changegroup part.
`hg debugbundle` is calling repr() on bundle2 part params, which are
now util.sortdict instances. Unfortunately, repr() doesn't appear
to be deterministic for util.sortdict. So, we implement one.
We include the type name because that's the common convention for
__repr__ implementations. Having the type name in `hg debugbundle`
is a bit ugly. But it's a debug command and I don't care enough to
fix it.
Before this patch shelve never preserved branch information,
so after applying unshelve branch was the same as it was
on working copy no matter in which branch shelve took place.
This patch makes bare shelving(with no files specified, without
interactive,include and exclude option) remembers information if
the working directory was on newly created branch ,in other words
working directory was on different branch than its first parent.
In this situation unshelving restores branch information to the working
directory.
If an emergency comes in while you're in the middle of an experimental
change, it can be useful to shelve not just files hg already tracks but
also your unknown files while you handle the emergency. This is
especially true if you have hooks intended to prevent you from
forgetting to add new code before you push.
Teach "hg shelve" to optionally shelve unknown files, not just tracked
files. This is functionally similar to --addremove, but with two
differences:
1) Deleted files are not removed.
2) Files added during shelve creation are tracked in extra so that they
can be forgotten by "hg unshelve".
When unshelving, we take care to only forget files if they've been
created during the unshelve operation; if you add a file that's being
tracked in a shelve as an unknown file, it should not become unknown
again when the shelve is unshelved.
If detailed conflict markers are enabled and the closing quote gets truncated,
editors will often screw syntax highlighting up from that point because they'll
see an opening quote and think it's the beginning of a string.
In tests, the hashes change because the commit messages of the shelved bundles
also change.
These are related to differences in how missing files and network connection
failures are displayed. I opted to combine the strings in one line instead of
using '#if windows' blocks around entire commands in order to avoid future
changes being accidentally missed in the Windows sections. Globbing away the
entire output seemed wrong, as it could mask other failures.
The raw messages involved are:
Linux Windows
"* not known" <-> "getaddrinfo failed"
"Connection refused" <-> "No connection could be made because the
target machine actively refused it"
"No such file or directory" <-> "The system cannot find the file specified"
Issue 4941 indicates that NetBSD has yet another string for "* not known".
Also, the histedit test shows that the missing file is printed first on Windows,
last on Linux. That is controlled in windows.py:posixfile if we care to change
it.
4bc805f938a0 made 'bmstore.write()' transaction sensitive, to restore
original bookmarks correctly at failure of a transaction.
For example, shelve and unshelve imply steps below:
before 4bc805f938a0:
1. move active bookmark forward at internal rebasing
2. 'bmstore.write()' writes updated ones into .hg/bookmarks
3. rollback transaction to remove internal commits
4. restore updated bookmarks manually
after 4bc805f938a0:
1. move active bookmark forward at internal rebasing
2. 'bmstore.write()' doesn't write updated ones into .hg/bookmarks
(these are written into .hg/bookmarks.pending, if external hook
is spawn)
3. rollback transaction to remove internal commits
4. .hg/bookmarks should be clean, because it isn't changed while
transaction running: see (2) above
But if shelve or unshelve is executed in the repository created with
"shared bookmarks" ("hg share -B"), this doesn't work as expected,
because:
- share extension makes 'bmstore.write()' write updated bookmarks
into .hg/bookmarks of shared source repository regardless of
transaction activity, and
- intentional transaction failure at the end of shelve/unshelve
doesn't restore already updated .hg/bookmarks of shared source
This patch makes share extension wrap 'bmstore._writerepo()' instead
of 'bmstore.write()', because the former is used to actually write
bookmark changes out.
