- Jul 01, 2015
-
-
Matt Mackall authored
-
- Jun 30, 2015
-
-
Pierre-Yves David authored
For some reason, transplant was pulling all remote revisions when transplanting from a remote repository (unless --branch was specified).
-
Pierre-Yves David authored
Transplant is apparently allowing using revision numbers when transplanting through http. I call this nonsense and update the test to use an explicit hash. This "feature" will break in the next change fixing another bug.
-
- Jun 29, 2015
-
-
Pierre-Yves David authored
The computation of roots was buggy, any ancestor of a bundled merge which was also a descendant of the parents of a bundled revision were included as part of the bundle. We fix it and add a test for strip (which revealed the problem). Check the test for a practical usecase.
-
- Jun 25, 2015
-
-
Yuya Nishihara authored
As of Mercurial 3.4, there were several syntax rules to process nested template strings. Unfortunately, they were inconsistent and conflicted each other. a. buildmap() rule - template string is _parsed_ as string, and parsed as template - <\"> is not allowed in nested template: {xs % "{f(\"{x}\")}"} -> parse error - template escaping <\{> is handled consistently: {xs % "\{x}"} -> escaped b. _evalifliteral() rule - template string is _interpreted_ as string, and parsed as template in crafted environment to avoid double processing of escape sequences - <\"> is allowed in nested template: {if(x, "{f(\"{x}\")}")} - <\{> and escape sequences in string literal in nested template are not handled well c. pad() rule - template string is first interpreted as string, and parsed as template, which means escape sequences are processed twice - <\"> is allowed in nested template: {pad("{xs % \"{x}\"}', 10)} Because of the issue of template escaping, issue4714, 7298da81f5a9 (in stable) unified the rule (b) to (a). Then, 576d6c74784b (in default) unified the rule (c) to (b) = (a). But they disabled the following syntax that was somewhat considered valid. {if(rev, "{if(rev, \"{rev}\")}")} {pad("{files % \"{file}\"}", 10)} So, this patch introduces \"...\" literal to work around the escaped-quoted nested template strings. Because this parsing rule exists only for the backward compatibility, it is designed to copy the behavior of old _evalifliteral() as possible. Future patches will introduce a better parsing rule similar to a command substitution of POSIX shells or a string interpolation of Ruby, where extra escapes won't be necessary at all. {pad("{files % "{file}"}", 10)} ~~~~~~~~~~~~~~~~~~ parsed as a template, not as a string Because <\> character wasn't allowed in a template fragment, this patch won't introduce more breakages. But the syntax of nested templates are interpreted differently by people, there might be unknown issues. So if we want, we could instead remove db7463aa080f, 890845af1ac2 and 7298da81f5a9 from the stable branch as the bug fixed by these patches existed for longer periods. 554d6fcc3c84, "strip single backslash before quotation mark in quoted template", should be superseded by this patch. I'll remove it later.
-
- Jun 26, 2015
-
-
Matt Harbison authored
Hardcoding '.' is wrong, and yielded strange results when archiving old revisions. For example, when archiving the cset that adds the signature to 3.4 (c48850339988), the resulting value was previously 51 (the number of commits on stable between 3.4 and today), even though it was a direct descendant of a tag, with a {latesttagdistance} of 2. This still includes all other _ancestor_ paths not included in {latesttag}. Note that archiving wdir() currently blows up several lines above this when building the 'base' variable. Since wdir() isn't documented, ignore that it needs work to handle wdir() here for now.
-
- Jun 21, 2015
-
-
Yuya Nishihara authored
The backslash character should start escape sequences no matter if a string is prefixed with 'r'. They are just not interpreted as escape sequences in raw strings. revset.tokenize() handles them correctly, but templater didn't. https://docs.python.org/2/reference/lexical_analysis.html#string-literals
-
- Jun 20, 2015
-
-
Yuya Nishihara authored
revset() had the same issue as 9452112c8eb0. It crashed by passing non-string expression.
-
Matt Harbison authored
Previously, both queries exited with code 1, printing nothing. The pattern in the latter query is normalized to '.', so it is really the same case.
-
- Jun 13, 2015
-
-
Yuya Nishihara authored
Before this patch, diff() crashed by passing non-string expression because it didn't evaluate arguments at all.
-
- Jun 12, 2015
-
-
Gregory Szorc authored
Index lookups raise RevlogError when the lookup fails. The previous implementation was caching a reference to the RevlogError type in a static variable. This assumed that the "mercurial.error" module was only loaded once and there was only a single copy of it floating around in memory. Unfortunately, in some situations - including certain mod_wsgi configurations - this was not the case: the "mercurial.error" module could be reloaded. It was possible for a "RevlogError" reference from the first interpreter to be used by a second interpreter. While the underlying thing was a "mercurial.error.RevlogError," the object IDs were different, so the Python code in revlog.py was failing to catch the exception! This error has existed since the C index lookup code was implemented in changeset e8d37b78acfb, which was first released in Mercurial 2.2 in 2012. http://emptysqua.re/blog/python-c-extensions-and-mod-wsgi/#static-variables-are-shared contains more details. This patch removes the caching of the RevlogError type from the function. Since pretty much the entire function was refactored and the return value of the function wasn't used, I changed the function signature to not return anything. For reasons unknown to me, we were calling PyErr_SetObject() with the type of RevlogError and an instance of RevlogError. This was equivalent to the Python code "raise RevlogError(RevlogError)". This seemed wonky and completely unnecessary. The Python code only cares about the type of the exception, not its contents. So I got rid of this complexity. This is my first Python C extension patch. Please give extra scrutiny to it during review.
-
- Jun 08, 2015
-
-
Yuya Nishihara authored
The problem was spotted at 5ab28a2e9962, that says "this patch invokes it with "strtoken='rawstring'" in "_evalifliteral()", because "t" is the result of "arg" evaluation and it should be "string-escape"-ed if "arg" is "string" expression." This workaround is no longer valid since 890845af1ac2 introduced strict parsing of '\{'. Instead, we should interpret bare token as "string" or "rawstring" template. This is what buildmap() does at parsing phase.
-
- Jun 05, 2015
-
-
Laurent Charignon authored
When moving crecord to core, I did a search an replace to remove all of the variable with caps letter. Doing so, I unfortunately changed some commands with capital letter shortcut to their lowercase counterpart. I fixed one of these cases in 093d38165e5a. This patch fixes all of the remaining cases.
-
Laurent Charignon authored
When moving crecord to core, I did a search an replace to remove all of the variable with caps letter. Doing so, I unfortunately changed the 'F' command to 'f' leading to two 'f' commands, one never used. This patch fixes this mistake and re enables the behavior of 'F'.
-
- Jun 01, 2015
-
-
Matt Harbison authored
Previously, if a subrepo parent had 'web.hidden=True' set, neither the parent nor child had a repository entry. However, the directory entry for the parent would be listed (it wouldn't have the fancy 'web.name' if configured), and that link went to the repo's summary page, effectively making it not hidden. This simply disables the directory processing if a valid repository is present. Whether or not the subrepo should be hidden is debatable, but this leaves that behavior unchanged (i.e. it stays hidden).
-
- Jun 03, 2015
-
-
Pierre-Yves David authored
The previous scheme was: 1) lookup node for all pulled revision, 2) pull said node 3) lookup the node of the checkout target 4) update the repository there. If the remote repo changes between (1) and (3), the resolved name will be different and (3) crash. There is actually no need for a remote lookup during (3), we could just set the value in (1). This prevent the race condition and save a possible network roundtrip.
-
- Jun 01, 2015
-
-
Matt Harbison authored
Previously, when 'web.name' was set on a subrepo parent and 'web.collapse=True', the parent repo would show in the list with the configured 'web.name', and a directory with the parent repo's filesystem name (with a trailing slash) would also appear. The subrepo(s) would unexpectedly be excluded from the list of repositories. Clicking the directory entry would go right to the repo page. Now both the parent and the subrepos show up, without the additional directory entry. The configured hgweb paths used '**' for finding the repos in this scenario. A couple of notes about the tests: - The area where the subrepo was added has a comment that it tests subrepos, though none previously existed there. One now does. - The 'web.descend' option is required for collapse to work. I'm not sure what the previous expectations were for the test. Nothing changed with it set, prior to adding the code in this patch. It is however required for this test. - The only output changes are for the hyperlinks, obviously because of the 'web.name' parameter. - Without this code change, there would be an additional diff: --- /usr/local/mercurial/tests/test-hgwebdir.t +++ /usr/local/mercurial/tests/test-hgwebdir.t.err @@ -951,7 +951,7 @@ /rcoll/notrepo/e/ /rcoll/notrepo/e/e2/ /rcoll/notrepo/f/ - /rcoll/notrepo/f/f2/ + /rcoll/notrepo/f/ Test repositories inside intermediate directories I'm not sure why the fancy name doesn't come out, but it is enough to demonstrate that the parent is not listed redundantly, and the subrepo isn't skipped.
-
Matt Mackall authored
-
Matt Mackall authored
-
Katsunori FUJIWARA authored
Before this patch, template keywords `{file_mods}`, `{file_adds}` and `{file_dels}` use values gotten by `repo.status(ctx.p1().node(), ctx.node())`. But this doesn't work as expected if `ctx` is `memctx` or `workingcommitctx`. Typical case of templating with these contexts is customization of the text shown in the commit message editor by `[committemplate]` configuration. In this case, `ctx.node()` returns None and it causes comparison between `ctx.p1()` and `workingctx`. `workingctx` lists up all changed files in the working directory even at selective committing. BTW, `{files}` uses `ctx.files()` and it works as expected. To compare target context and its parent exactly, this patch passes `ctx.p1()` and `ctx` without `node()`-nize. This avoids unexpected comparison with `workingctx`. This patch uses a little redundant template configurations in `test-commit.t`, but they are needed to avoid regression around problems fixed by a4958cdb2202 and 1e6fb8db666e: accessing on `ctx` may break `ctx._status` field.
-
Katsunori FUJIWARA authored
-
- May 29, 2015
-
-
Durham Goode authored
The --keep option was being serialized to the state file, but it wasn't actually being used when running a histedit --continue. This fixes that.
-
- May 27, 2015
-
-
Matt Mackall authored
Mercurial uses tags of null to mark deletions, but convert was silently discarding these because it had no mapping for them. Thus, it was resurrecting deleted tags.
-
- May 26, 2015
-
-
Pierre-Yves David authored
The fix in fd905b2bea59 is actually wrong. We now use the filename to match what '_addentry'. This whole untested code is quite suspicious. This seems to point that no one is ever running 'tr.find' for a backup file.
-
Matt Mackall authored
checkcopies was using fctx.rev() which it was expecting would be equivalent to linkrev() but was triggering the new _adjustlinkrev path. This was making grafts and merges with large sets of potential copies very expensive.
-
- May 24, 2015
-
-
Katsunori FUJIWARA authored
Before this patch, hook argument `txnid` isn't passed to `pretxnopen` hooks, even though `hooks` section of `hg help config` describes so. ``pretxnopen`` Run before any new repository transaction is open. The reason for the transaction will be in ``$HG_TXNNAME`` and a unique identifier for the transaction will be in ``HG_TXNID``. A non-zero status will prevent the transaction from being opened.
-
Katsunori FUJIWARA authored
Before this patch, transaction ID (TXNID) is calculated from `transaction` object itself by `id()`, but this prevents TXNID from being passed to `pretxnopen` hooks, which should be executed before starting transaction processing (also any preparations for it, like writing journal files out). As a preparation for passing TXNID to `pretxnopen` hooks, this patch separates calculation of TXNID from creation of `transaction` object. This patch uses "random" library for reasonable unique ID. "uuid" library can't be used, because it was introduced since Python 2.5 and isn't suitable for Mercurial 3.4.x stable line. `%f` formatting for `random.random()` is used with explicit precision number 40, because default precision for `%f` is 6. 40 should be long enough, even if 10**9 transactions are executed in a short time (a second or less). On the other hand, `time.time()` is used to ensures uniqueness of TXNID in a long time, for safety. BTW, platform not providing `/dev/urandom` or so may cause failure of `import random` itself with some Python versions (see Python issue15340 for detail http://bugs.python.org/issue15340). But this patch uses "random" without any workaround, because: - "random" is already used directly in some code paths, - such platforms are very rare (e.g. Tru64 and HPUX), and http://bugs.python.org/issue15340#msg170000 - updating Python runtime can avoid this issue
-
- May 23, 2015
-
-
Yuya Nishihara authored
This fixes the crash caused by "branch(null)" revset. No cache should be necessary for nullrev because changelog.branchinfo(nullrev) does not involve IO operation. Note that the problem of "branch(wdir())" isn't addressed by this patch. "wdir()" will raise TypeError in many places because of None. This is the reason why "wdir()" is still experimental.
-
- May 24, 2015
-
-
Yuya Nishihara authored
This patch partially backs out d2de20e1451f and adds an alternative workaround to functions that evaluate "null" and "wdir()". Because the new workaround is incomplete, "first(null)" and "min(null)" don't work as expected. But they were not usable until 3.4 and "null" isn't commonly used, we can postpone a complete fix for 3.5. The issue4682 was caused because "branch(default)" is evaluated to "<filteredset <fullreposet>>", keeping fullreposet magic. The next patch will fix crash on "branch(null)", but without this patch, it would make "null in <branch(default)>" be True, which means "children(branch(default))" would return all revisions but merge (p2 != null). I believe the right fix is to stop propagating fullreposet magic on filter(), but it wouldn't fit to stable release. Also, we should discuss how to handle "null" and "wdir()" in revset before.
-
- May 22, 2015
-
-
Pierre-Yves David authored
The 'file' variable was undefined but resolved to the 'file' built-in. This is why pylint complains about overwriting built-ins...
-
Wagner Bruna authored
-
- May 19, 2015
-
-
Katsunori FUJIWARA authored
Before this patch, "the reason for the transaction" is passed to `pretxnclose` hooks via wrong name argument `xnname` (`HG_XNNAME` for external hooks)
-
Katsunori FUJIWARA authored
From the first (3.4 or d283517b260b), `TXNID` is passed to Python hooks without lowering its name, but it is wrong.
-
- May 18, 2015
-
-
Matt Harbison authored
The files command supports naming directories to limit the output to children of that directory, and it also supports -S to force recursion into a subrepo. But previously, using -S and naming a subrepo caused nothing to be output. The reason was narrowmatcher() strips the current subrepo path off of each file, which would leave an empty list if only the subrepo was named. When matching on workingctx, dirstate.matches() would see the submatcher is not always(), so it returned the list of files in dmap for each file in the matcher- namely, an empty list. If a directory in a subrepo was named, the output was as expected, so this was inconsistent. The 'not anypats()' check is enforced by an existing test around line 140: $ hg remove -I 're:.*.txt' sub1 Without the check, this removed all of the files in the subrepo.
-
- May 17, 2015
-
-
Matt Harbison authored
Previously, the first added test printed the following: $ hg files -S -r '.^' sub1/sub2/folder sub1/sub2/folder: no such file in rev 9bb10eebee29 sub1/sub2/folder: no such file in rev 9bb10eebee29 sub1/sub2/folder/test.txt One warning occured each time a subrepo was crossed into. The second test ensures that the matcher copy stays in place. Without the copy, the bad() function becomes an increasingly longer chain, and no message would be printed out for a file missing in the subrepo because the predicate would match in one of the replaced methods. Manifest doesn't know anything about subrepos, so it needs help ignoring subrepos when complaining about bad files.
-
- May 19, 2015
-
-
Pierre-Yves David authored
I just discovered that we are not displaying ssh server output in real time anymore. So we can just fall back to the bundle2 output capture for now. This fix the race condition issue we where seeing in tests. Re-instating real time output for ssh would fix the issue too but lets get the test to pass first.
-
- May 15, 2015
-
-
Tony Tung authored
After a rebase --abort, we attempt to restore the previously active bookmark. We need to ensure that the bookmark still exists.
-
Yuya Nishihara authored
Instead of keeping 'onlypost' as a method, this patch rewrites it to 'only' function. This way, 'x%' always has the same weight as 'only(x)'.
-
- May 10, 2015
-
-
Jordi Gutiérrez Hermoso authored
The check of the inrebase function was not correct, and it failed to consider the situation in which nothing has been rebased yet, *and* the working dir had been updated away from the initial revision. But this is easy to fix. Given the rebase state, we know exactly where we should be standing: on the first unrebased commit. We check that instead. I also took the liberty to rename the function, as "inrebase" doesn't really describe the situation: we could still be in a rebase state yet the user somehow forcibly updated to a different revision. We also check that we're in a merge state, since an interrupted merge is the only "safe" way to interrupt a rebase. If the rebase got interrupted by power loss or whatever (so there's no merge state), it's still safer to not blow away the working directory.
-
Jordi Gutiérrez Hermoso authored
The fix for issue4009, namely fe78eb7bcca0, introduced issue4661. Let's make sure that the fix for issue4661 will not reintroduce issue4009.
-