templatekw: expose color name in {namespaces} entries 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.

show: construct changeset templater during dispatch 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.

cmdutil: use named arguments for changeset_templater.__init__ This will make the API more extensible and easier to use.

bundle: inline applybundle1() We have now gotten rid of all but one caller, so let's inline it there.

bundle: make applybundle() delegate v1 bundles to applybundle1()

bundle: transpose transaction scope with bundle type switch This moves the transaction with-statements outside of the per-bundle-version switches, so the next patch will be a little simpler.

unbundle: move BundleUnknownFeatureError exception handling out 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.

bundle: make applybundle1() return a bundleoperation See previous commit for motivation. It already lets us share a little bit more code in commands.py.

bundle: add a applybundle1() method 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.

bundle: extract _processchangegroup() method 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.

bundle: make combinechangegroupresults() take a bundleoperation Both callers have a bundleoperation. Passing it in lets us share a bit more code.

bundle: move combineresults() from changegroup to bundle2 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.

bundle: remove 'op' argument from applybundle() No callers pass in an operation.

test-rebase-conflicts: add a test case about turning obsstore on and off 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.

merge with stable

strip: include phases in bundle (BC) 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.

bundle: add config option to include phases 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.

bundle2: record changegroup data in 'op.records' (API) 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().

debugcommands: pass part, not read data, into _debugobsmarker() This matches how it's done for _debugchangegroup() and how we will soon do it for _debugphaseheads().

debugcommands: remove unused "all" argument from _debugobsmarkers

dagop: raise ProgrammingError if stopdepth < 0 revset.py should never send such a value.

make: add Debian 9 (Stretch) docker target

make: templatize Debian build target a la e63dfbbdbd07

make: add Ubuntu Zesty docker targets (.deb and ppa) Zesty Zapus was released on 2017-04-13 and will be supported until 2018-01.

docker: install less as a build-time dependency in deb-based distros It's needed since 387a76cac28e, otherwise dpkg-checkbuilddeps errors out.

py3: add utility to forward __str__() to __bytes__() It calls unifromlocal() instead of sysstr() because __bytes__() may contain locale-dependent values such as paths.

share: use dict literal instead of dict(key=value) check-code.py has the rule, but it isn't smart enough to catch this.

py3: use r'' to prevent conversion to bytes by transformer

py3: define __bytes__ for basefilectx class The implementation is shamely copied from the __str__ function

py3: check for bytes instead of str in isinstance