- Aug 22, 2017
- Aug 23, 2017
-
-
Durham Goode authored
This moves the bundle2 part handling for bundlerepo out to a separate function so extensions can participate in bundlerepo setup when using bundle2 bundles. Differential Revision: https://phab.mercurial-scm.org/D290
-
Durham Goode authored
Previously, iterparts would yield the part to users, then consume the part. This changed the part after the user was given it and left it at the end, both of which seem unexpected. Let's seek back to the beginning after we've consumed it. I tried not seeking to the end at all, but that seems important for the overall bundle2 consumption. This is used in a future patch to let us move the bundlerepo bundle2-changegroup-part to be handled entirely within the for loop, instead of having to do a seek back to 0 after the entire loop finishes. Differential Revision: https://phab.mercurial-scm.org/D289
-
Durham Goode authored
A future patch will refactor certain parts of bundlerepo initiatlization such that we need to create temp bundles from another function. Let's move this to another function to support that. Differential Revision: https://phab.mercurial-scm.org/D288
-
- Aug 17, 2017
-
-
Martin von Zweigbergk authored
The Mercurial core server doesn't yet include phase-heads parts in the bundle, but our Google-internal server wants to do that. Unfortunately, the usual exchange still happens even if phase-heads part is included (including the short-circuited one for old/publishing servers). That means that even if our server (again, the Google-internal one, but also future Mercurial core servers) includes a phase-heads part to indicate that some heads should be drafts, that would still get overwritten by the phase updating that happens after. So let's fix that by marking the phase step done if we receive at least one phase-heads part in the bundle. Differential Revision: https://phab.mercurial-scm.org/D440
-
- Aug 16, 2017
-
-
Jun Wu authored
Setting `repo._shellvars` works but is not a clean way to pass the pushvars information from the push command to the exchange operation. Therefore change it to actually pass `pushvars` as a push operation argument instead. This makes third party extension like remotenames easier to support pushvars cleanly. The key value parsing and verification code has been moved to a lower level so it's harder to be bypassed and easier to be used in remotenames which could replace `push` command entirely. Differential Revision: https://phab.mercurial-scm.org/D423
-
- Aug 21, 2017
-
-
Pulkit Goyal authored
There are cases like bisect when the conflict message can be None. So we make sure that we don't print None in that case. Thanks to Martin for catching this. Differential Revision: https://phab.mercurial-scm.org/D461
-
- Aug 23, 2017
-
-
Alex Gaynor authored
Differential Revision: https://phab.mercurial-scm.org/D482
-
- Aug 13, 2017
-
-
Rishabh Madan authored
While using releasenotes extension, we will be using admonitions in commit messages. The check (-c) flag will look for an admonition within the message. If it exists, it will verify if it is stated under default or custom admonition. The check fails if the admonition is not present in any of them. It also suggests similar admonitions in case the admonition is invalid. Differential Revision: https://phab.mercurial-scm.org/D368
-
- Aug 22, 2017
-
-
Gábor Stefanik authored
-
Gábor Stefanik authored
"will not be limited" was meant to be "will not be visited". I missed this when writing the original graft-through-rename patch series.
-
durin42 authored
-
durin42 authored
The doctests now do some regrettable things, but they'll always work since we're dealing with ASCII module names etc.
-
durin42 authored
-
durin42 authored
-
durin42 authored
We don't need the fallback to the old modules anymore.
-
durin42 authored
-
durin42 authored
I didn't do anything to ensure correctness here, just enough to avoid tracebacks in the import checker, which uses the native ast module to try and parse all our Python files.
-
- Aug 23, 2017
-
-
Alex Gaynor authored
Differential Revision: https://phab.mercurial-scm.org/D483
-
- Aug 22, 2017
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D478
-
Martin von Zweigbergk authored
With the .t files highlighted, it's very easy to not even notice failed .py tests. Differential Revision: https://phab.mercurial-scm.org/D471
-
- Aug 20, 2017
-
-
Jun Wu authored
chg currently triggers `reposetup` as a side effect of `hg serve` command. Therefore change the test to not output during `reposetup` to be compatible with chg. Differential Revision: https://phab.mercurial-scm.org/D455
-
- Aug 19, 2017
-
-
Yuya Nishihara authored
This enables the optimization introduced by d4247c306d82 for non-rebase cases. Before, the match couldn't be narrowed if it was e.g. alwaysmatcher. The logic is copied from bd56bea5ecf8.
-
- Aug 22, 2017
-
-
Matthieu Laneuville authored
Pre instantiate pygments objects to minimize overhead (cf. 20436925e080)
-
Sean Farley authored
-
- Aug 11, 2017
-
-
Jun Wu authored
When the code executes to _finishrebase, self.state should be populated with correct destinations and do not need to be written to a node. The code was introduced by 8dc45c905989, which seems to avoid setting state values to None but it didn't provide more details. Differential Revision: https://phab.mercurial-scm.org/D346
-
Jun Wu authored
Previously, when there are 2 merge base candidates, we choose p1 blindly, which may make the merge result to have "unwanted content". This patch makes rebase smarter - choose a merge base that does not have "unwanted revs" if possible. Since we don't really have a good solution when there are "unwanted revs", abort in that case. Differential Revision: https://phab.mercurial-scm.org/D340
-
- Aug 16, 2017
-
-
Martin von Zweigbergk authored
As Augie reported in the bug, the current heuristic of choosing the best tag of a merge commit by taking the one with newest tag (in terms of tagging date) currently fails in the Mercurial repo itself. Copying the example from Yuya: $ hg glog -T '{node|short} {latesttag}+{latesttagdistance}\n' \ -r '4.2.3: & (merge() + parents(merge()) + tag())' o 02a745c20121 4.2.3+5 |\ | o 86aca74a063b 4.2.3+4 | |\ | | o e6d8ee3c9ec3 4.3-rc+109 | | | | | ~ o | a3ce07e2dde5 4.3.1+2 : | o | 3fee7f7d2da0 4.3.1+0 |/ o 98e990bb7330 4.2.3+3 |\ | ~ o 506d7e48fbe6 4.2.3+2 : o 943c91326b23 4.2.3+0 | ~ It seems to me like the best choice is the tag with the smallest number of changes since it (across all paths, not the longest single path). So that's what this patch does, even though it's costly. Best-of-5 timings for Yuya's command above shows a slowdown from 1.293s to 1.610s. We can optimize it later. Differential Revision: https://phab.mercurial-scm.org/D447
-
- Aug 18, 2017
-
-
Martin von Zweigbergk authored
The tests are much easier to read if one does not have to re-read the setup part all the time to understand the graph shape. Differential Revision: https://phab.mercurial-scm.org/D446
-
- Aug 16, 2017
-
-
Jun Wu authored
In chg's case, making modules lazily loaded could actually slow down things since chg pre-imports them. Therefore disable demandimport if chg is being used. This is not done by setting `HGDEMANDIMPORT` chg client-side because that has side-effects on child processes (hooks, etc). Differential Revision: https://phab.mercurial-scm.org/D351
-
- Aug 18, 2017
-
-
Jun Wu authored
The logic is now shared between demandimport{2,3}. Differential Revision: https://phab.mercurial-scm.org/D445
-
- Aug 15, 2017
-
-
Danny Hooper authored
Wrapping text in templates for 'hg log --graph' can't be done very well, because the template doesn't know how wide the graph drawing is. The edge drawing function needs to know the number of lines in the template output, so we need to also determine how wide that drawing would be before we call the edgefn or evaluate the template. This patch makes edgefn compute the graph width and pass it into the template so that we can do something like this: COLUMNS=10 hg log --graph --template "{fill(desc, termwidth - graphwidth)}" @ a a a a | a a a a | a a a a o a a a |\ a a a | | a a a | | a a a Using extensions to do this would be relatively complicated due to a lack of hooks in this area of the code. In the future it may make sense to have a more generic "textwidth" that tells you how many columns you can expect to fill without causing the terminal to wrap your output. I'm not sure there are other situations to motivate this yet, or if it is entirely feasible. Differential Revision: https://phab.mercurial-scm.org/D360
-