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 a preparation for using 'repo.rollback()' instead of aborting
a current running transaction for "shelve" and "unshelve".
Before this patch, updating files as a part of 'repo.rollback()'
overridden by keyword extension always follows 'restrict' mode of the
command currently executed.
"merge", "unshelve" and so on should be 'restrict'-ed, because keyword
expansion may cause unexpected conflicts at merging while these
commands.
But, if 'repo.rollback()' is invoked while executing 'restrict'-ed
commands, modified files in the working directory are marked as
"CLEAN" unexpectedly by code path below:
# 'lookup' below is True at updating modified files for rollback
kwcmd = self.restrict and lookup # kwexpand/kwshrink
:
if kwcmd:
self.repo.dirstate.normal(f)
On the other hand, "rollback" command isn't 'restrict'-ed, because
rollbacking itself doesn't imply merging.
Therefore, disabling 'restrict' mode while updating files as a part of
'repo.rollback()' regardless of current 'restrict' mode should be
reasonable.
Extension authors (notably at companies using hg) have been
cargo-culting the `testedwith = 'internal'` bit from hg's own
extensions, which then defeats our "file bugs over here" logic in
dispatch. Let's be more aggressive about trying to give extension
authors a hint about what testedwith should say.
This function doesn't need access to any of the args or kwargs, so make the
monkeypatching more robust. (In upcoming patches we'll introduce another
argument to patch.diff, and this function would break if it weren't for this
patch.)
Although Python supports `X = Y if COND else Z`, this was only
introduced in Python 2.5. Since we have to support Python 2.4, it was
a very common thing to write instead `X = COND and Y or Z`, which is a
bit obscure at a glance. It requires some intricate knowledge of
Python to understand how to parse these one-liners.
We change instead all of these one-liners to 4-liners. This was
executed with the following perlism:
find -name "*.py" -exec perl -pi -e 's,(\s*)([\.\w]+) = \(?(\S+)\s+and\s+(\S*)\)?\s+or\s+(\S*)$,$1if $3:\n$1 $2 = $4\n$1else:\n$1 $2 = $5,' {} \;
I tweaked the following cases from the automatic Perl output:
prev = (parents and parents[0]) or nullid
port = (use_ssl and 443 or 80)
cwd = (pats and repo.getcwd()) or ''
rename = fctx and webutil.renamelink(fctx) or []
ctx = fctx and fctx or ctx
self.base = (mapfile and os.path.dirname(mapfile)) or ''
I also added some newlines wherever they seemd appropriate for readability
There are probably a few ersatz ternary operators still in the code
somewhere, lurking away from the power of a simple regex.
This change touches every module in which repository.wopener was being used, and
changes it for the equivalent repository.wvfs.
It should now be possible to remove localrepo.wopener.
This change touches every module in which repository.sopener was being used, and
changes it for the equivalent repository.svfs.
It should now be possible to remove localrepo.sopener.
This change touches every module in which repository.opener was being used, and
changes it for the equivalent repository.vfs. This is meant to make it easier
to split the repository.vfs into several separate vfs.
It should now be possible to remove localrepo.opener.
Merged files are considered modified at commit time even if only 1 parent
differs. In this case we must use the change context of this parent for
expansion.
The issue went unnoticed for long because it is only apparent until the next
update to the merge revision - except in test-keyword where it was always
staring us in the face.
Instead of calling repo[None].status(), use the more common form that
uses the parent of the working copy as the base:
repo['.'].status(). Note that the former defaults to comparing to
revision '.', while the latter defaults to revision None, so the
contexts being compared are the same.
It might seem like this would result in a reverse diff, but it turns
out that workingctx.status() incorrectly reverses the result. That bug
will be fixed in a later commit.
Before this patch, 'hg fetch' may cause unexpected conflict, if 'hg
fetch'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg fetch' for internal
merge by adding 'fetch' to 'restricted' command list like 'merge'.
This patch uses 'hg import' to safely create the new head to be merged
at succeeding 'hg fetch', because:
- branch of revision #10 is different from one of #11 in 'Test'
repository, so just 'hg fetch -r 11' doesn't cause merging between
them
this means the new head should be created manually.
- 'hg import' is easier and safer than 'cat <<EOF' and 'hg commit'
to replay same changes including special characters like '$'
safeness of 'hg import' with keyword extension is already examined
in 'test-keyword.t'.
Before this patch, 'hg histedit' may cause unexpected conflict, if 'hg
histedit'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg histedit' for
internal merge by adding 'histedit' to 'restricted' command list like
'merge'.
Test in this patch just swaps order of revision #13 and #14: this is
enough to cause internal merge.
Before this patch, 'hg backout' may cause unexpected conflict, if 'hg
backout'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg backout' for
internal merge by adding 'backout' to 'restricted' command list like
'merge'.
Before this patch, 'hg graft' may cause unexpected conflict, if 'hg
graft'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg graft' for internal
merge by adding 'graft' to 'restricted' command list like 'merge'.
Before this patch, 'hg rebase' may cause unexpected conflict, if 'hg
rebase'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg rebase' for internal
merge by adding 'rebase' to 'restricted' command list like 'merge'.
This patch specifies '--keep' to 'hg rebase', because revision #10 is
useful also for tests in succeeding patches.
Before this patch, 'hg unshelve' may cause unexpected conflict, if 'hg
unshelve'-ed changes are located near lines in which keywords are
embedded, because keywords are substituted with other strings in the
working directory.
This patch suppresses keyword expansion while 'hg unshelve' for
internal merge by adding 'unshelve' to 'restricted' command list like
'merge'.
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.
A repo should not get the configuration from an other repo, so create it with
the global configuration in repo.baseui.
This is done too when recreating a repo. The repo configuration is reread
anyway. And now deleted repo configuration does not persist.
Maintain a whitelist of commands to infer the repo for instead. The whitelist
contains those commands that take file(s) in the working dir as arguments.
