templater: add i18n comments to error messages of newly added functions This patch adds i18n comments to error messages of newly added functions "startswith" (introduced by 4a445dc5abff) and "word" (by 8f23f8096606).

commands: make the warning message for "patch --partial" translatable This patch makes the warning message for "patch --partial" translatable: this message was introduced by bee0e1cffdd3, and there is no reason to prevent this from being translatable.

convert: fix argument mismatch at formatting the abort message This patch fixes argument mismatch at formatting the abort message, introduced by a204fd9b5ba9: the last '%s' doesn't have corresponded argument. This patch uses "unexpected size" in the abort message, to distinguish the reason of failure from "unexpected type" failure checked in the prior code path below: if info[1] != type: raise util.Abort(_('cannot read %r object at %s') % (type, rev))

debuginstall: handle quoted path for editor (issue4316) When using an editor path with spaces and options, you can set 'ui.editor' to '"/path to your/editor" -opt' and it works fine but 'hg debuginstall' is complaining about it because it simply splits the editor and tests presence of '"/path'. Now correctly parse 'ui.editor' string by handling quoted path.

test-bundle2: move file mode setting after sys import

config: allow 'user' in .hgrc ui section (issue3169)

merge with i18n

i18n-pt_BR: synchronized with ad56fc55cbc3

doc: unify help text for "--edit" option This patch changes help text for "--edit" option of commands below: - fetch - qnew - qrefresh - qfold - commit - tag This unification reduces translation cost, too. This patch chooses not "further edit commit message already specified" (of "hg commit") but "invoke editor on commit messages" as unified help text for "--edit" option, because the latter is much older than the former.

doc: unify help text for "--message" option This patch changes help text for "--message" option of commands below for unification. - sign (of gpg) - tag This unification reduces translation cost, too. This patch doesn't change the description for "--message" of "hg rebase" below, because this should contain "collapse" word to explain its purpose (only for "--collapse") clearly. use text as collapse commit message

histedit: respect revsetalias entries (issue4311) We now expand user-provided revsets before using repo.revs() to locate the root(s) of the user-specified set.

graft: add a reference to revsets to the help text (issue3362)

i18n: add parenthesis in Brazilian translation of the resolve message Eu falo brasileiro agora. Eu não sou uma batata!

resolve: add parenthesis around "no more unresolved files" message This message may be confused with an error message. Adding parenthesis around it will make it more recognisable as an informative message.

help: mention '-T list' in templater topic

help: drop reference to glog in templates topic

templates: re-add template listing support We used to have --style nosuch to list templates, but --style is now merged with --template/-T where random strings are acceptable templates. So we reserve 'list' to allow listing templates.

help: use --template to specify existing style --style is deprecated since 3a35ba2681ec and 870d60294b04.

test-status: add test for removed-and-untracked state (BC) In Mercurial 3.0, "hg status" can list the same file twice if it was removed but still exists in working directory, i.e. removed by "hg forget": $ hg status --rev 0 removed R removed ? removed But since 65cdc6bab91e, untracked state, "?", is no longer displayed in this example. I think the new behavior is correct since a file should have single state, but if it is a bug, this patch should be dropped.

bundle2: only use callable return as reply handler When a bundle2 parts generator returns a non callable value, it should not be used as a reply handler. The changegroup part generator is already having this case of behavior when there is no changegroup to push. This changeset prevent a crash for user of the experimentable bundle2 feature.

resolve: report no argument warning using a hint With this change resolve and revert produce consistent output when run with no arguments: $ hg resolve abort: no files or directories specified (use --all to remerge all files) $ hg revert abort: no files or directories specified (use --all to revert all files)

revset: optimize baseset.__sub__ (issue4313) dd716807fd23 regressed performance of baseset.__sub__ by introducing a lazyset. This patch restores that lost performance by eagerly evaluating baseset.__sub__ if the other set is a baseset. revsetbenchmark.py results impacted by this change: revset #6: roots(0::tip) 0) wall 2.923473 comb 2.920000 user 2.920000 sys 0.000000 (best of 4) 1) wall 0.077614 comb 0.080000 user 0.080000 sys 0.000000 (best of 100) revset #23: roots((0:tip)::) 0) wall 2.875178 comb 2.880000 user 2.880000 sys 0.000000 (best of 4) 1) wall 0.154519 comb 0.150000 user 0.150000 sys 0.000000 (best of 61) On the author's machine, this slowdown manifested during evaluation of 'roots(%ln::)' in phases.retractboundary after unbundling the Firefox repository. Using `time hg unbundle firefox.hg` as a benchmark: Before: 8:00 After: 4:28 Delta: -3:32 For reference, the subset and cs baseset instances impacted by this change were of lengths 193634 and 193627, respectively. Explicit test coverage of roots(%ln::), while similar to the existing roots(0::tip) benchmark, has been added.

memctx: substate needs to be {} instead of None Setting substate to None was an oversight in 7cfd94ec5d30 and this patch corrects it by setting substate to an empty dictionary which matches what subrepo code expects.

version: don't traceback if no extensions to list (issue4312)

merge with i18n

i18n-pt_BR: synchronized with 6c36dc6cd61a

largefiles: use "normallookup" on "lfdirstate" while reverting Before this patch, largefiles gotten from revisions other than the parent of the working directory at "hg revert" become "clean" unexpectedly in steps below: 1. "repo.status()" is invoked (for status check before reverting) 1-1 "dirstate" entry for standinfile SF is "normal"-ed (1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed) 2. "cmdutil.revert()" is invoked 2-1 standinfile SF is updated in the working directory 2-2 "dirstate" entry for SF is NOT updated 3. "lfcommands.updatelfiles()" is invoked (by "overrides.overriderevert()") 3-1 largefile LF (for SF) is updated in the working directory 3-2 "dirstate" returns "n" and valid timestamp for SF (by 1-1 and 2-2) 3-3 "lfdirstate" entry for LF is "normal"-ed 3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and timestamp of LF is stored into "lfdirstate" file (by 3-3) (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file) Then, "hs status" treats LF as "clean", even though LF is updated by "other" revision (by 3-1), because "lfilesrepo.status()" always treats "normal"-ed files (by 3-3 and 3-4) as "clean". When largefiles are reverted, they should be "normallookup"-ed forcibly. This patch uses "normallookup" on "lfdirstate" while reverting, by passing "True" to newly added argument "normallookup". Forcible "normallookup"-ing is not so expensive, because list of target largefiles is explicitly specified in this case. This patch uses "[debug] dirstate.delaywrite" feature in the test, to ensure that timestamp of the largefile gotten from "other" revision is stored into ".hg/largefiles/dirstate" (for ASSUMPTION at 3-4)

largefiles: invoke "normallookup" on "lfdirstate" for merged files Before this patch, largefiles gotten from "other" revision (with conflict) at "hg merge" become "clean" unexpectedly in steps below: 1. "repo.status()" is invoked (for status check before merging) 1-1 "dirstate" entry for standinfile SF is "normal"-ed 1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed 2. "merge.update()" is invoked 2-1 SF is updated in the working directory (ASSUMPTION: user choice "other" at conflict) 2-2 "dirstate" entry for SF is "merge"-ed 3. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()") 3-1 largefile LF (for SF) is updated in the working directory 3-2 "dirstate" returns "m" for SF (by 2-2) 3-3 "lfdirstate" entry for LF is left as it is 3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and timestamp of LF is stored into "lfdirstate" file (by 1-2) (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file) Then, "hs status" treats LF as "clean", even though LF is updated by "other" revision (by 3-1), because "lfilesrepo.status()" always treats "normal"-ed files (by 1-2 and 3-4) as "clean". When state of standinfile in "dirstate" is "m", largefile should be "normallookup"-ed. This patch invokes "normallookup" on "lfdirstate" for merged files. This patch uses "[debug] dirstate.delaywrite" feature in the test, to ensure that timestamp of the largefile gotten from "other" revision is stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 3-4)

largefiles: use "normallookup", if "mtime" of standin is unset Before this patch, largefiles gotten from "other" revision (without conflict) at "hg merge" become "clean" unexpectedly in steps below: 1. "merge.update()" is invoked 1-1 standinfile SF is updated in the working directory 1-2 "dirstate" entry for SF is "normallookup"-ed 2. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()") 2-1 largefile LF (for SF) is updated in the working directory 2-2 "dirstate" returns "n" for SF (by 1-2) 2-3 "lfdirstate" entry for LF is "normal"-ed 2-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and timestamp of LF is stored into "lfdirstate" file (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file) Then, "hs status" treats LF as "clean", even though LF is updated by "other" revision (by 2-1), because "lfilesrepo.status()" always treats "normal"-ed files (by 2-3 and 2-4) as "clean". When timestamp is not set (= negative value) for standinfile in "dirstate", largefile should be "normallookup"-ed regardless of rebasing or not, because "n" state in "dirstate" doesn't ensure "clean"-ness of a standinfile at that time. This patch uses "normallookup" instead of "normal", if "mtime" of standin is unset This is a temporary way to fix with less changes. For fundamental resolution of this kind of problems in the future, "lfdirstate" should be updated with "dirstate" simultaneously while "merge.update" execution: maybe by hooking "recordupdates" It is also why this patch (temporarily) uses internal field "_map" of "dirstate" directly. This patch uses "[debug] dirstate.delaywrite" feature in the test, to ensure that timestamp of the largefile gotten from "other" revision is stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 2-4) This patch newly adds "test-largefiles-update.t", to avoid increasing cost to run other tests for largefiles by subsequent patches (especially, "[debug] dirstate.delaywrite" causes so).

dirstate: delay writing out to ensure timestamp of each entries explicitly Even though "dirstate.write()" is invoked explicitly after "normal" invocations, timestamp field of entries may be still "unset" in the "dirstate" file itself , because "pack_dirstate" drops it when it is equal to the timestamp of "dirstate" file itself. This can avoid overlooking modification of files, which are updated at same time in the second. But on the other hand, this may hide timing critical problems. For example, incorrect "normal"-ing (or lack of "normallookup"-ing on the already "normal"-ed entry) is visible only when: - the target file is modified in the working directory at T1, and - "dirstate" file is written out at T2 (!= T1) Otherwise, T1 is dropped by "pack_dirstate" in "dirstate.write()" invocation, and "unset" is stored into "dirstate" file. It often fails to reproduce problems from incorrect "normal"-ing by Mercurial testset, because automated actions in the small repository almost always causes that T1 and T2 are same. This patch adds the debug feature to delay writing out to ensure timestamp of each entries explicitly. This feature is used to make timing critical "dirstate" problems reproducable in subsequent patches.