- Sep 28, 2018
-
-
Pulkit Goyal authored
Recently we introduced narrow capabilities for the server. So we can check whether a server has narrow clone support or not before doing anything. This is BC because new clients won't be able to extend from old narrow-enabled servers. I *think* narrow is not used much (maybe just inside Google), also it's experimental so I think we can change this. We will need to this someday anyway. The "doesn't" in error is changed to "does not" because I think that's we do in core. I also changed one more instance of the error message to use 'does not' for consistency. Differential Revision: https://phab.mercurial-scm.org/D4789
-
- Sep 30, 2018
-
-
Pulkit Goyal authored
I believe we set dirstate parents to nullid before widening pull because in ellipses cases, the parent might be stripped off with a new changeset. However the second ds.setparents() call invalidate my assumption. I am not sure why we do this. So here is a patch. This patch also adds tests showing we break nothing in non-ellipses cases. Differential Revision: https://phab.mercurial-scm.org/D4788
-
- Sep 28, 2018
-
-
Pulkit Goyal authored
Extensions inspect the `source` parameter and add some custom logic on the basis of value of that parameter. The parameter is also passed to hooks. So let's pass the value as 'narrow_widen' to differentiate widening from pull. Differential Revision: https://phab.mercurial-scm.org/D4787
-
Pulkit Goyal authored
This patch takes out the logic which generates a changegroup for widening a narrow clone when ellipses are disabled. This is done because future patches will introduce a narrow_widen() wireprotocol command which will send a bundle2 with changegroup and will use this function. The new function for now returns just the changegroup for compatibility with existing code, but in future patches, when we establish a wireprotocol command and call this function from there, this will return the required bundle2. Differential Revision: https://phab.mercurial-scm.org/D4786
-
- Oct 01, 2018
-
-
Martin von Zweigbergk authored
The narrow extension overrides the dirstate editing functions to restrict paths outside the narrowspec. These overrides access the dirstate from repo.dirstate instead of using the "self" reference passed to the overridden functions. I don't see a reason for this and it caused me problems with a later patch (it caused infinite recursion when I modified localrepo.dirstate()), so let's change it. Differential Revision: https://phab.mercurial-scm.org/D4829
-
- Sep 27, 2018
-
-
Martin von Zweigbergk authored
localrepo.__getitem__ special-cased lookup of the working copy parent to avoid looking up obsmarkers. I think the reason for that code (which I once wrote myself) was to make `hg commit` not load obsmarkers, which it would otherwise do via ctx.p1() in localrepo.commitctx(). That had the somewhat unfortunate consequence of making lookup of an unrelated binary nodeid load the dirstate. Now that changectx's constructor is dumb, we can let workingctx._parents() have the opmtimization instead. This affects two tests, because they no longer end up loading the dirstate and their "warning: ignoring unknown working parent ..." messages therefore go way. Differential Revision: https://phab.mercurial-scm.org/D4828
-
Martin von Zweigbergk authored
My motivation for this change was to make repo[node] not load the dirstate (more about that in the next patch), but I think it makes more sense this way too. For example, raising RepoLookupError seems to belong better in the repo lookup function (i.e. localrepo.__getitem__). This makes the changectx constructor very simple -- it just assigns the given repo, revnum, and nodeid to properties. Differential Revision: https://phab.mercurial-scm.org/D4827
-
Martin von Zweigbergk authored
I want to change the constructor's signature and letting all creation of changectx instances go through the repo simplifies that. Differential Revision: https://phab.mercurial-scm.org/D4826
-
- Oct 02, 2018
-
-
Gregory Szorc authored
res.headers is holding system strings. Attempting to compare against bytes always fails and we fail to print decoded CBOR responses on Python 3. After this change, various test-wireproto* tests are now properly printing CBOR response objects. Differential Revision: https://phab.mercurial-scm.org/D4835
-
Gregory Szorc authored
The low-level request object ideally takes system strings for HTTP request headers and values. If we send in bytes, it works. But a duplicate header check fails and various tests emit duplicate user-agent headers. Differential Revision: https://phab.mercurial-scm.org/D4834
-
Gregory Szorc authored
Previously the source transformer was converting some string literals to bytes and we were comparing a system native string to bytes and this was leading to sending the wrong HTTP response headers on Python 3. After this change, we now properly send Transfer-Encoding and Connection response headers on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4833
-
Gregory Szorc authored
The test now passed on Python 3. # skip-blame just b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D4836
-
Pulkit Goyal authored
84092edd5c88 removed narrowpatch.py and wanted to drop narrowpatch from __init__.py but mistakenly removed narrowcopies. This will make buildbots green again. Differential Revision: https://phab.mercurial-scm.org/D4837
-
Matt Harbison authored
I missed these in 803b7569c9ea because I forgot about `...` lines.
-
Matt Harbison authored
-
Matt Harbison authored
This is needed to keep py3 happy. The other two instances of sorting already did this.
-
Matt Harbison authored
There's still a stacktrace about not being able to serialize _io.TextIOWrapper.
-
Matt Harbison authored
-
- Oct 01, 2018
-
-
Matt Harbison authored
-
- Jun 22, 2018
-
-
Martin von Zweigbergk authored
By inlining it, we also avoid calculating the value when "if of in seen" is false (probably not significant). Differential Revision: https://phab.mercurial-scm.org/D4831
-
- Sep 16, 2018
-
-
Martin von Zweigbergk authored
"parentrepo" and "repo" were the same thing and I don't see much reason for it (unionrepo has similar structure and a similar alias but there are two repos there so at least it makes a little more sense there). Differential Revision: https://phab.mercurial-scm.org/D4830
-
- Oct 01, 2018
-
-
Augie Fackler authored
-
durin42 authored
-
durin42 authored
-
- Sep 05, 2018
-
-
Yuya Nishihara authored
Spotted by ASAN.
-
Yuya Nishihara authored
Even though the entire manifest data should be terminated by '\0', it seems not nice to scan '\0' over the entry terminator, '\n'.
-
- Sep 28, 2018
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D4824
-
Martin von Zweigbergk authored
The patch overrides became unnecessary when I made context.status() filter by the narrowspec in e411774a2e0f (narrow: move status-filtering to core and to ctx, 2018-08-02). Differential Revision: https://phab.mercurial-scm.org/D4823
-
Martin von Zweigbergk authored
We had a test that shows that trying to explicitly add a file outside the narrowspec results in an error, but we didn't have a test that shows that paths from subdirectories outside the narrowspec are not added (on e.g. `hg add .`) but silently ignored. Differential Revision: https://phab.mercurial-scm.org/D4822
-
- Oct 01, 2018
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D4818
-
- Sep 29, 2018
-
-
Pulkit Goyal authored
This will be used in core logic to determining whether a server is ellipses enabled or not. And also this will ease moving narrow related things to core. Differential Revision: https://phab.mercurial-scm.org/D4809
-
Pulkit Goyal authored
We are trying to integrate the whole of narrow logic into core and it will be helpful for upcoming patches to have these capability names in core. The next patch will move the ellipses capability to core also. The exact motivation is to know whether we are cloning a ellipses repo or not and adding an ellipses repo requirement. Differential Revision: https://phab.mercurial-scm.org/D4808
-
- Sep 30, 2018
-
-
Yuya Nishihara authored
-
Yuya Nishihara authored
I think it's good enough to stabilize the feature, at least for the core and non-experimental commands.
-
Yuya Nishihara authored
-
Yuya Nishihara authored
I think {lineno} looks more like a common template keyword. It isn't called a {line} to avoid conflicts with the element name of {lines} and the {_|splitlines} filter. https://www.mercurial-scm.org/wiki/GenericTemplatingPlan#Dictionary
-
Yuya Nishihara authored
This is a part of the name unification. I think it's somewhat useful to provide a combined view of change/merge statuses. https://www.mercurial-scm.org/wiki/GenericTemplatingPlan#Dictionary
-
- Oct 01, 2018
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D4817
-
- Nov 03, 2017
-
-
Boris Feld authored
We detected that pager is waiting for log-to-process script to finish, which is annoying when adding a script on commandfinish that does an HTTP push. There seems to be no workaround on the script side and it will make the behavior on Linux/MacOS closer to the Windows behavior. The drawback is that it makes the related tests more flaky as log-to-process outputs are now really asynchronous. If it's considered a BC change, another option would be to add a config option for this new behavior. I personally think that the different behavior between Windows and Linux is confusing and that it's a bug I would be fine with a new config option. Differential Revision: https://phab.mercurial-scm.org/D4816
-
Boris Feld authored
The next changeset will fix the bad interaction between the pager and log-to- process. Add a test first to make the next changeset easier to understand. Differential Revision: https://phab.mercurial-scm.org/D4815
-