I've caught multiple extensions in the wild lying about being
'internal', so it's time to move the goalposts on people. Goalpost
moving will continue until third party extensions stop trying to
defeat the system.
68ae3063a47d causes a fatal AttributeError if kwdemo is run outside a repo
because in the temporary repo creation repo is None and therefore cannot have a
baseui attribute.
In this case fall back to using ui.
Add test case.
Before this patch, "missing _() in ui message" rule overlooks
translatable message, which starts with other than alphabet.
To detect "missing _() in ui message" more exactly, this patch
improves the regexp with assumptions below.
- sequence consisting of below might precede "translatable message"
in same string token
- formatting string, which starts with '%'
- escaped character, which starts with 'b' (as replacement of '\\'), or
- characters other than '%', 'b' and 'x' (as replacement of alphabet)
- any string tokens might precede a string token, which contains
"translatable message"
This patch builds an input file, which is used to examine "missing _()
in ui message" detection, before '"$check_code" stringjoin.py' in
test-contrib-check-code.t, because this reduces amount of change churn
in subsequent patch.
This patch also applies "()" instead of "_()" on messages below to
hide false-positives:
- messages for ui.debug() or debug commands/tools
- contrib/debugshell.py
- hgext/win32mbcs.py (ui.write() is used, though)
- mercurial/commands.py
- _debugchangegroup
- debugindex
- debuglocks
- debugrevlog
- debugrevspec
- debugtemplate
- untranslatable messages
- doc/gendoc.py (ReST specific text)
- hgext/hgk.py (permission string)
- hgext/keyword.py (text written into configuration file)
- mercurial/cmdutil.py (formatting strings for JSON)
Since (b) is banned, we should do the same for (a) for consistency.
a) from mercurial import hg
from mercurial.i18n import _
b) from . import hg
from .i18n import _
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.