- Oct 01, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Sep 30, 2014
-
-
Jordi Gutiérrez Hermoso authored
Since 3fbef7ac26f0, we have a diff.nobinary option. This is handy, but the only way I found out about it was by looking at the release notes for 3.1, which is not something I normally do.
-
Wagner Bruna authored
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Sep 22, 2014
-
-
Wagner Bruna authored
-
- Sep 30, 2014
-
-
Yuya Nishihara authored
Since e3eb480a9391, --template option is ignored if --style is specified, which is wrong according to the doc of show_changeset(): Display format will be the first non-empty hit of: 1. option 'template' 2. option 'style' ...
-
- Sep 27, 2014
-
-
Anton Shestakov authored
Make hgweb.refresh() also look at phaseroots file (in addition to 00changelog.i file) and reload the repo when os.stat returns different mtime or size than cached, signifying the file was modified. This way if user changes phase of a changeset (secret <-> draft), there's no need to restart hg serve to see the change.
-
- Sep 29, 2014
-
-
Matt Mackall authored
-
- Sep 22, 2014
-
-
Anton Shestakov authored
Traditionally, the way to specify a command for hgweb was to use url query arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an error (e.g. "400 no such method: badcmd"). But there's also another way to specify a command: as a url path fragment (e.g. "/graph"). Before, hgweb was made forgiving (looks like it was made in 44c5157474e7) and user could put any unknown command in the url. If hgweb couldn't understand it, it would just silently fall back to the default command, which depends on the actual style (e.g. for paper it's shortlog, for monoblue it's summary). This was inconsistent and was breaking some tools that rely on http status codes (as noted in the issue4071). So this patch changes that behavior to the more consistent one, i.e. hgweb will now return "400 no such method: badcmd". So if some tool was relying on having an invalid command return http status code 200 and also have some information, then it will stop working. That is, if somebody typed foobar when they really meant shortlog (and the user was lucky enough to choose a style where the default command is shortlog too), that fact will now be revealed. Code-wise, the changed if block is only relevant when there's no "?cmd" query parameter (i.e. only when command is specified as a url path fragment), and looks like the removed else branch was there only for falling back to default command. With that removed, the rest of the code works as expected: it looks at the command, and if it's not known, raises a proper ErrorResponse exception with an appropriate message. Evidently, there were no tests that required the old behavior. But, frankly, I don't know any way to tell if anyone actually exploited such forgiving behavior in some in-house tool.
-
- Sep 24, 2014
-
-
Mike Hommey authored
The code in keepalive dates from when it was importing the md5 module directly and uses md5.new. Since then, what 'md5' means has been changed from an import of the md5 module to being a function using the right module between hashlib and md5, so the md5.new idiom doesn't work anymore.
-
- Sep 17, 2014
-
-
Pierre-Yves David authored
The baseset class is based on a python list. This means that base.__contains__ was absolutely as crappy as list.__contains__. We now rely on __contains__ from the underlying set. This will avoid having to explicitly convert the baseset to a set (using baseset.set()) whenever one want fast membership test. Apparently there is already code that forgot to do such conversions since we observe a massive speedup in some test. revset #25: roots((0::) - (0::tip)) 0) wall 2.079454 comb 2.080000 user 2.080000 sys 0.000000 (best of 5) 1) wall 0.132970 comb 0.130000 user 0.130000 sys 0.000000 (best of 65) No regression is observed in benchmarks. This change improve the issue4371 back to acceptable situation (but are still slower than manual substraction)
-
- Sep 21, 2014
-
-
Matt Mackall authored
-
Matt Mackall 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
-