- Aug 01, 2014
-
-
Yuya Nishihara authored
e2530d4a47c1 is valid only if file argument is specified. If no pattern specified, it can simply fall back to the original matcher.
-
- Jul 31, 2014
-
-
Matt Mackall authored
When an import fails, this doesn't lose the state for the earlier revisions.
-
Matt Mackall authored
-
Matt Mackall authored
-
Katsunori FUJIWARA authored
-
Matt Mackall authored
Old behavior: hg help x hg x -h hg help -e x hg help -c x config topic topic (!) - cmd showconfig cmd topic (!) - cmd rebase cmd cmd ext cmd New behavior: hg help x hg x -h hg help -e x hg help -c x config topic cmd - cmd showconfig cmd cmd - cmd rebase cmd cmd ext cmd
-
Katsunori FUJIWARA authored
This patch adds i18n comments to error messages of newly added functions "startswith" (introduced by 4a445dc5abff) and "word" (by 8f23f8096606).
-
Katsunori FUJIWARA authored
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.
-
Katsunori FUJIWARA authored
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))
-
Alexandre Garnier authored
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.
-
- Jul 30, 2014
-
-
Matt Mackall authored
-
- Jul 26, 2014
-
-
anatoly techtonik authored
-
- Jul 30, 2014
-
-
Matt Mackall authored
-
- Jul 29, 2014
-
-
Wagner Bruna authored
-
Katsunori FUJIWARA authored
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.
-
Katsunori FUJIWARA authored
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
-
- Jul 28, 2014
-
-
durin42 authored
We now expand user-provided revsets before using repo.revs() to locate the root(s) of the user-specified set.
-
Alexander Becher authored
-
- Jul 26, 2014
-
-
Pierre-Yves David authored
Eu falo brasileiro agora. Eu não sou uma batata!
-
Pierre-Yves David authored
This message may be confused with an error message. Adding parenthesis around it will make it more recognisable as an informative message.
-
- Jul 25, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
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.
-
- Jul 21, 2014
-
-
Yuya Nishihara authored
--style is deprecated since 3a35ba2681ec and 870d60294b04.
-
- Jul 24, 2014
-
-
Yuya Nishihara authored
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.
-
- Jul 02, 2014
-
-
Pierre-Yves David authored
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.
-
- Jul 24, 2014
-
-
Nathan Goldbaum authored
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)
-
Gregory Szorc authored
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.
-
- Jul 16, 2014
-
-
Sean Farley authored
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.
-
- Jul 23, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Jul 20, 2014
-
-
Wagner Bruna authored
-
- Jul 22, 2014
-
-
Katsunori FUJIWARA authored
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)
-
Katsunori FUJIWARA authored
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)
-
Katsunori FUJIWARA authored
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).
-
Katsunori FUJIWARA authored
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.
-
- Jul 21, 2014
-
-
Danek Duvall authored
-
- Jul 20, 2014
-
-
Wagner Bruna authored
-
- Jul 19, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-