- Sep 22, 2014
-
-
Wagner Bruna authored
-
- Sep 11, 2014
-
-
Katsunori FUJIWARA authored
Before this patch, "hg qselect" with --pop/--reapply may pop patches unexpectedly, even when all of patches applied before "qselect" are still pushable. Strictly speaking about the condition of this issue: - before "qselect" - there are N applied patches - the index of the guarded patch X in the series is less than N - after "qselect" - X is still guarded, and - all of applied patched are still pushable In the case above, "hg qselect" should keep current status, but it actually tries to pop patches because of X. The index in "the series" should be used to examine "pushable" of a patch by "mq.pushablek()", but the index in "applied patches" is used, and this may cause unexpected examination of guarded patch. To examine "pushable" of already applied patch correctly, this patch uses "mq.applied[i].name": "pushable" is the function introduced by the previous patch, and it returns "mq.pushable(mq.applied[i].name)[0]".
-
Katsunori FUJIWARA authored
Before this patch, "hg qselect" with --pop/--reapply may pop incorrect patches, because the index in "applied patches" is used to pop patches by "mq.pop()", even though the index in "the series" should be used. For example, when the already applied patch becomes guarded and it follows the already guarded (= not yet applied) one, "hg qselect" is aborted, because it tries to pop to guarded one. This patch uses "mq.applied[i - 1].name" to pop to the patch, of which the index in the "applied ones" is "i - 1".
-
Katsunori FUJIWARA authored
Before this patch, "hg qselect --reapply" is aborted when "--verbose" is specified, because "mq.appliedname()" returns "INDEX PATCHNAME" instead of "PATCHNAME" in such case and "mq.push" can't accept the former as the name of patch. This patch uses "mq.applied[i].name" instead of "mq.appliedname(i)" as the name of the patch to be pushed for safety. Now, there is no code path using "mq.appliedname()", and it should be removed to prevent developers from using it in the wrong way like this issue.
-
Katsunori FUJIWARA authored
Before this patch, "hg qselect" may report incorrect numbers for "number of guarded, applied patches has changed", because it examines "pushable" of patches by the index not in "the series" but in "applied patches", even though "mq.pushable()" expects the former. To report correct numbers for changing "number of guarded, applied patches", this patch uses the name of applied patch to examine pushable-ness of it. This patch also changes the result of existing "hg qselect" tests, because they doesn't change pushable-ness of already applied patches. This patch assumes that "hg qselect" focuses on changing pushable-ness only of already applied patches, because: - the report message uses not "previous" (in the series) but "applied" - the logic to pop patches for --pop/--reapply examines pushable-ness only of already applied ones (in fact, there are some incorrect code paths)
-
- Sep 09, 2014
-
-
Katsunori FUJIWARA authored
Before this patch, the shell alias causes failure when it takes its specific (= unknown for "hg") options in the command line, because "_parse()" can't accept them. This is the regression introduced by 03d345da0579. It fixed the issue that ambiguity between shell aliases and commands defined by extensions was ignored. But it also caused that ambiguous shell alias is handled in "_parse()" even if it takes specific options in the command line. To avoid such failure, this patch checks shell alias again after loading extensions. All aliases and commands (including ones defined by extensions) are completely defined before the 2nd (= newly added in this patch) "_checkshellalias()" invocation, and "cmdutil.findcmd(strict=False)" can detect ambiguity between them correctly. For efficiency, this patch does: - omit the 2nd "_checkshellalias()" invocation if "[ui] strict= True" it causes "cmdutil.findcmd(strict=True)", of which result should be equal to one of the 1st invocation before adding aliases - avoid removing the 1st "_checkshellalias()" invocation it causes "cmdutil.findcmd(strict=True)" invocation preventing shell alias execution from loading extensions uselessly
-
Katsunori FUJIWARA authored
To reduce changes in the subsequent patch fixing issue4355, this patch makes "_checkshellalias" reusable regardless of adding aliases. In this patch, alias definitions are added and restored, only when "precheck=True".
-
- Sep 03, 2014
-
-
Siddharth Agarwal authored
Previously we'd print an ugly message saying that the histedit-state file doesn't exist in the repo.
-
- Sep 02, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Sep 01, 2014
-
- Aug 30, 2014
-
-
Gregory Szorc authored
`hg help -k` on my machine was aborting because the hg-prompt extension was inserting a string and not a function into help.helptable and help was blindly calling it. This patch changes keyword searching to be more robust against unexpected types.
-
- Sep 01, 2014
-
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Aug 31, 2014
-
-
Katsunori FUJIWARA authored
-
- Aug 30, 2014
-
-
Wagner Bruna authored
-
- Aug 31, 2014
-
-
Mike Hommey authored
Incidentally, this avoids the changelog cache being invalidated each time it's accessed on a repoview. On a filtering experiment on a repository the size of mozilla-central, this makes a significant difference: Before, running hg log -l 10 --time with about 8k changesets filtered out: time: real 1.490 secs (user 1.450+0.000 sys 0.040+0.000) After: time: real 0.540 secs (user 0.530+0.000 sys 0.010+0.000)
-
- Aug 19, 2014
-
-
Aaron Kushner authored
When running 'hg config no_such_option', hg exited with a zero exit code. This change now exits with a 1 if the config option does not exist.
-
- Aug 30, 2014
-
-
Kevin Bullock authored
This is a follow-on to 0c6cdbb697d9 that just makes a slight clarification.
-
- Aug 27, 2014
-
-
Katsunori FUJIWARA authored
Before this patch, no message is shown for failure of merging at "hg import". In such case, merging patch is imported as a normal revision silently, and it may confuse users. For simplicity, this patch recommends just using "--exact", even though importing the merging patch itself is possible without it if: - the hash of the 1st parent in the patch is equal to one of the patch imported just before (or the parent of the working directory, for the 1st patch of the series), and - the hash of the 2nd parent in the patch is known in the local repository
-
Mads Kiilerich authored
When grafting something with a matching origin, it would normally be skipped: skipping already grafted revision 123 (23 also has origin 12) But after stripping a graft origin, graft could fail with a reference to the origin that no longer exists: abort: unknown revision '5c095ad7e90f871700f02dd1fa5012cb4498a2d4'! Instead, detect that the origin is unknown and skip it anyway, like: skipping already grafted revision 8 (2 also has unknown origin 5c095ad7e90f871700f02dd1fa5012cb4498a2d4)
-
- Aug 23, 2014
-
-
Sean Farley authored
Previously, there was a copy / paste error with using the current changeset's phase information. We now look up the parent context explicitly. The line was too long so it is stored into a variable first.
-
- Aug 25, 2014
-
-
Thomas De Schampheleire authored
Commit aa51392da507 introduced a pad function for use in templates, but did not add the corresponding documentation to 'hg help templating'.
-
- Aug 15, 2014
-
-
Mads Kiilerich authored
Pull would send a getbundle command where common heads were sent both as common and head, even though there is no reason to request a common head. The request was thus twice as big as necessary and more likely to hit HTTP header size limits. Instead, don't request heads that already are common. This is fixed in bundlerepo.getremotechanges . It could perhaps also have been fixed in discovery.findcommonincoming but that would have a bigger impact.
-
Mads Kiilerich authored
-
Mads Kiilerich authored
The value '*' currently designates that bid merge should be used. The best way to test bid merge is to set preferancestor=* in the configuration file ... but then it would abort with unknown revision '*' when other code paths ended up in changectx.ancestor . Instead, just skip and ignore the value '*' when looking for a preferred ancestor.
-
Mads Kiilerich authored
Updates with uncommited changes will always only have one ancestor - the parent revision. Updates between existing revision should (and will) always give the same result no matter which ancestor is used. The warning is thus only relevant when doing a "real" merge.
-
- Aug 14, 2014
-
-
Pierre-Yves David authored
When a remote is not capable of the `branchmap` wireproto command, we denote incoming heads with None. This leads to a crash in the code in charge of displaying the list of unknown remote heads. We now properly detect this case and display a shorter message in this case. The reason for this `set([None])` value is now documented.
-
Pierre-Yves David authored
We detect when there is a cycle in the marker itself (precursors being listed as successors).
-
Pierre-Yves David authored
There are already a couple of errors that obsstore.create can raise and we are going to introduce a cycle check too.
-
Matt Mackall authored
-
- Aug 13, 2014
-
-
Siddharth Agarwal authored
This was the one case for test-largefiles that was not broken.
-
Siddharth Agarwal authored
This makes hg log --follow --patch work, since in cmdutil._makelogrevset we use the non-follow matcher for hg log --follow --patch with no file arguments.
-
Siddharth Agarwal authored
This has actually been broken since at least Mercurial 2.8 -- hg log --patch with largefiles only used to work when no largefiles existed. Rev 5809d62e7106 exposed this bug for all cases.
-
Siddharth Agarwal authored
lfstatus should only be True for operations where we want standins to be printed out. We explicitly do not want that for historical operations like log. Other historical operations like hg diff -r A -r B don't print out standins either. This is required to fix issue4334, but doesn't fix anything by itself. That's why there aren't any tests accompanying this patch.
-
Siddharth Agarwal authored
This will be used by largefiles (and basically only by largefiles) in an upcoming patch.
-
Siddharth Agarwal authored
We're going to add a _makenofollowlogfilematcher in an upcoming patch.
-
Martin von Zweigbergk authored
When the authorship of the changeset folded in does not match that of the base changeset, we currently use the configured ui.username instead. This is especially surprising when the user is not the author of either of the changesets. In such cases, the resulting authorship (the user's) is clearly incorrect. Even when the user is folding in a patch they authored themselves, it's not clear whether they should take over the authorship. Let's instead keep it simple and always preserve the base changeset's authorship. This is also how "git rebase -i" handles folding/squashing.
-
Matt Mackall authored
backported from default
-
Matt Mackall authored
-