- Jun 25, 2017
-
-
Katsunori FUJIWARA authored
Before this patch, kwweb_skip doesn't restore kwtemplater.match after wrapped webcommands. This suppresses keyword expansion at wrapped webcommands. Typical usecase of this issue is "file" webcommand after annotate, changeset, filediff or so on. To ensure kwtemplater.match=util.never while original webcommand running, this patch makes kwweb_skip yield values returned by it, because it returns generator object.
-
Katsunori FUJIWARA authored
Before this patch, kwdiff doesn't restore kwtemplater.restrict after invocation of wrapped patch.diff(). This suppresses keyword expansion at subsequent filelog.read(). Typical usecase of this issue is "hg cat" after "hg diff" with command server. In this case, kwtemplater.restrict=True is kept in command server process even after "hg diff". To ensure kwtemplater.restrict=True while original patch.diff() running, this patch makes kwdiff() yield values returned by it, because it returns generator object. Strictly speaking, if filelog.read() is invoked before completely evaluating the result of previous patch.diff(), keyword expansion is still suppressed, because kwtemplater.restrict isn't restored yet. But this fixing should be reasonable enough, because patch.diff() is consumed immediately, AFAIK.
-
- Jun 26, 2017
-
-
Yuya Nishihara authored
I think this is what the max(...) exists for.
-
- Jun 23, 2017
-
-
Pierre-Yves David authored
That item default value is a bit special (None) so this adds a second proof that everything is still working fine.
-
- Jun 25, 2017
-
-
Pierre-Yves David authored
This will prevent bugs from using None as the sentinel value (eg: 'ui.interactive')
-
Pierre-Yves David authored
This will prevent bugs from using None as the sentinel value (eg: 'ui.interactive')
-
Pierre-Yves David authored
This will make it easier for the other 'configxxx' function to detect unset value.
-
- Jun 22, 2017
-
-
Pierre-Yves David authored
Mercurial read all data between the base of the chain and the last delta when restoring content (including unrelated delta). To monitor this, we add data about the size of the "delta chain span" to debugrevlog.
-
- Jun 25, 2017
-
-
Jun Wu authored
Previously, rebase assumes the following pattern: rebase: with transaction as tr: # top-level ... tr.__close__ writes rebasestate unlink('rebasestate') However it's possible that "rebase" was called inside a transaction: with transaction as tr1: rebase: with transaction as tr2: # not top-level ... tr2.__close__ does not write rebasestate unlink('rebasestate') tr1.__close__ writes rebasestate That leaves a rebasestate on disk incorrectly. This patch adds "removefilegenerator" to notify transaction code that the state file is no longer needed therefore fixes the issue.
-
Jun Wu authored
The test demonstrates that .hg/rebasestate is left behind if "rebase" was called inside an existing transaction.
-
Matt Harbison authored
I meant to do this before sending the initial templater support, but forgot. I'm quite surprised that 'dirty' doesn't occur in more user facing contexts, but there are a few, like the help for blackbox. It also more obviously mirrors the '(clean)' state printed by the summary command. I also didn't like that it was just one letter off from {changes} in the {latesttags} sub-keywords, which has a totally different meaning.
-
- Jun 23, 2017
-
-
Katsunori FUJIWARA authored
Now, there is no user for dispatch._loaded.
-
Katsunori FUJIWARA authored
Before this patch, functions defined in extensions are registered via extra loaders only in _dispatch(). Therefore, loading extensions in other code paths like below omits registration of functions. - WSGI service - operation across repositories (e.g. subrepo) - test-duplicateoptions.py, using extensions.loadall() directly To register functions always at loading new extension, this patch moves implementation for extra loading from dispatch._dispatch() to extensions.loadall(). AFAIK, only commands module causes cyclic dependency between extensions module, but this patch imports all related modules just before extra loading in loadall(), in order to centralize them. This patch makes extensions.py depend on many other modules, even though extensions.py itself doesn't. It should be avoided if possible, but I don't have any better idea. Some other places like below aren't reasonable for extra loading, IMHO. - specific function in newly added module: existing callers of extensions.loadall() should invoke it, too - hg.repository() or so: no-repo commands aren't covered by this. BTW, this patch removes _loaded.add(name) on relocation, because dispatch._loaded is used only for extraloaders (for similar reason, "exts" variable is removed, too).
-
- Jun 25, 2017
-
-
Matt Harbison authored
This is based on a patch proposed last year by Mathias De Maré[1], with a few changes. - Tags and bookmarks are now formatted lists, for more flexible queries. - The templater is populated whether or not [-nibtB] is specified. (Plain output is unchanged.) This seems more consistent with other templated commands. - The 'id' property is a string, instead of a list. - The parents of 'wdir()' have their own list of attributes. I left 'id' as a string because it seems very useful for generating version info. It's also a bit strange because the value and meaning changes depending on whether or not --debug is passed (short vs full hash), whether the revision is a merge or not (one hash or two, separated by a '+'), the working directory or not (node vs p1node), and local or not (remote defaults to tip, and never has '+'). The equivalent string built with {rev} seems much less useful, and I couldn't think of a reasonable name, so I left it out. The discussion seemed to be pointing towards having a list of nodes, with more than one entry for a merge. It seems simpler to give the nodes a name, and use {node} for the actual commit probed, especially now that there is a virtual node for 'wdir()'. Yuya mentioned using fm.nested() in that thread, so I did for the parent nodes. I'm not sure if the plan is to fill in all of the context attributes in these items, or if these nested items should simply be made {p1node} and {p1rev}. I used ':' as the tag separator for consistency with {tags} in the log templater. Likewise, bookmarks are separated by a space for consistency with the corresponding log template. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-August/087039.html
-
- Jun 24, 2017
-
-
Gregory Szorc authored
This commit addresses a number of deficiencies in `hg show work`'s output: * Failure to render tags (it just wasn't implemented) * Failure to render names associated with non-built-in namespaces (e.g. remotenames) * Color names were hardcoded instead of coming from the canonical source in the namespace This change has the intended effect of rendering tags and extra namespaces. It solves an immediate need at Mozilla of having names from a custom namespace printed, which is blocking us from switching from a custom `hg wip` revset/template combo to `hg show work`. Note that the order of branches and bookmarks changes. This is because bookmarks are registered before branches in namespaces.py. We may want to register them last, after tags and branches. Or we may want to added a weighted field to the namespace to control display order. Something to think about. I'm not a big fan of the complexity in the templating layer. There is a lot of code to basically filter out the special case of branch=='default' and tag=='tip'. Ideally, we would iterate over a data structure that had irrelevant/unwanted names pre-filtered. However, I wasn't sure how to best implement this. We probably want {namespaces} to emit everything (its current behavior). I was toying with the following: * {namespacesnondefaults} variation that filtered values * A filter function that operated on {namespaces} (I wasn't sure how to implement this since the filtering layer would see a "hybrid" instance as opposed to something that was definitely an iterable of namespaces.) * A namespaces(...) function where you could specify which values to return. I like this the most. But it really wants named arguments to control filtering and we only support named arguments on revsets, not templates. I figure perfect is the enemy of good and we can refine templating support for namespaces in the future. At least now we have a concrete example of a use case.
-
Gregory Szorc authored
This demonstrates some missing features. This will also help verify that a subsequent change has the intended effect.
-
Gregory Szorc authored
Currently, the templating layer tends to treat each namespace as a one-off, with explicit usage of {bookmarks}, {tags}, {branch}, etc instead of using {namespaces}. It would be really useful if we could iterate over namespaces and operate on them generically. However, some consumers may wish to differentiate namespaces by whether they are built-in to core Mercurial or provided by extensions. Expected use cases include ignoring non-built-in namespaces or emitting a generic label for non-built-in namespaces. This commit introduces an attribute on namespace instances that says whether the namespace is "built-in" and then exposes this to the templating layer. As part of this, we implement a reusable extension for defining custom names on each changeset for testing. A second consumer will be introduced in a subsequent commit.
-
Gregory Szorc authored
Templates make use of a "log.<namespace>" label. The <namespace> value here differs from the actual namespace name in that the namespace itself is plural but the label/color value is singular. Expose the color name to the templating layer so log.* labels can be emitted for {namespaces}. As part of this, we refactored the logic to eliminate a gnarly comprehension. We store color names in their own dict because the lookup can occur in tight loops and we shouldn't have to go to repo.names[ns] multiple times for every changeset.
-
Gregory Szorc authored
Previously, we constructed a formatter from a specific template topic. Then from show() we reached into the internals of the formatter to resolve a template string to be used to construct a changeset templater. A downside to this approach was it limited us to having the entire template defined in a single entry in the map file. You couldn't reference other entries in the map file and this would lead to long templates and redundancy in the map file. This commit teaches @showview how to instantiate a changeset templater so we can construct a templater with full access to the map file. To prove it works, we've split "showwork" into components.
-
Gregory Szorc authored
This will make the API more extensible and easier to use.
-
- Jun 23, 2017
-
-
Martin von Zweigbergk authored
We have now gotten rid of all but one caller, so let's inline it there.
-
- Jun 22, 2017
-
-
Martin von Zweigbergk authored
-
- Jun 23, 2017
-
-
Martin von Zweigbergk authored
This moves the transaction with-statements outside of the per-bundle-version switches, so the next patch will be a little simpler.
-
- Jun 22, 2017
-
-
Martin von Zweigbergk authored
This just moves the BundleUnknownFeatureError exception handling one level up so we collect the bundle2.applybundle{,1}() calls together. applybundle1() will never throw the exception, so it should have no functional consequence.
-
Martin von Zweigbergk authored
See previous commit for motivation. It already lets us share a little bit more code in commands.py.
-
- Jun 16, 2017
-
-
Martin von Zweigbergk authored
This is one step towards removing a bunch of "if isinstance(gen, unbundle20)" by treating bundle1 and bundle2 more similarly. The name may sounds ironic for a method in the bundle2 module, but I didn't think it was worth it yet to create a new 'bundle' module that depends on the 'bundle2' module. Besides, we'll inline the method again later.
-
- Jun 22, 2017
-
-
Martin von Zweigbergk authored
The new method applies the changegroup and fills in op.records, sharing a little bit of code between the two callers. We'll add another caller soon.
-
Martin von Zweigbergk authored
Both callers have a bundleoperation. Passing it in lets us share a bit more code.
-
Martin von Zweigbergk authored
The results only need to be combined if they come from a bundle2. More importantly, we'll change its argument to a bundleoperation soon, and then it definitely will no longer belong in changegroup.py.
-
- Jun 21, 2017
-
-
Martin von Zweigbergk authored
No callers pass in an operation.
-
- Jun 24, 2017
-
-
Jun Wu authored
Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series.
-
Augie Fackler authored
-
- Jun 15, 2017
-
-
Martin von Zweigbergk authored
Before this patch, unbundling a stripped changeset would make it a draft (unless the parent was secret). This meant that one would lose phase information when stripping and unbundling secret changesets. The same thing was true for public changesets. While stripping public changesets is generally rare, it's done frequently by e.g. the narrowhg extension. We also include the phases in the temporary bundle, just in case stripping were to fail after that point, so the user can still restore the repo including phase information. Before this patch, the phases were left untouched during the bundling and unbundling of the temporary bundle. Only at the end of the transaction would phasecache.filterunknown() be called to remove phase roots that were no longer valid. We now need to call that also after the first stripping, i.e. before applying the temporary bundle. Otherwise unbundling the temporary bundle will cause a read of the phase cache which has stripped changesets in the cache and that fails. Like with obsmarkers, we unconditionally include the phases in the bundle when stripping (when using bundle2, such as when generaldelta is enabled). The reason for doing that for strip but not for bundle is that strip bundles are not meant to be shared outside the repo, so we don't care as much about compatibility.
-
- Jun 22, 2017
-
-
Martin von Zweigbergk authored
This adds an experimental.bundle-phases config option to include phase information in bundles. As with the recently added support for bundling obsmarkers, the support for bundling phases is hidden behind the config option until we decide to make a bundlespec v3 that includes phases (and obsmarkers and ...). We could perhaps use the listkeys format for this, but that's considered obsolete according to Pierre-Yves. Instead, we introduce a new "phase-heads" bundle part. The new part contains the phase heads among the set of bundled revisions. It does not include those in secret phase; any head in the bundle that is not mentioned in the phase-heads part is assumed to be secret. As a special case, an empty phase-heads part thus means that any changesets should be added in secret phase. (If we ever add a fourth phase, we'll include secret in the part and we'll add a version number.) For now, phases are only included by "hg bundle", and not by e.g. strip and rebase.
-
- Jun 16, 2017
-
-
Martin von Zweigbergk authored
When adding support for bundling and unbundling phases, it will be useful to have the list of added changesets. To do that, we return the list from changegroup.apply().
-
- Jun 22, 2017
-
-
Martin von Zweigbergk authored
This matches how it's done for _debugchangegroup() and how we will soon do it for _debugphaseheads().
-
Martin von Zweigbergk authored
-
- Jun 24, 2017
-
-
Martin von Zweigbergk authored
revset.py should never send such a value.
-
- Jun 23, 2017
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-