patchbomb: drop internal option for pbranch extension (API) I want to move _getpatches() to _getpatchmsgs() to make sure each patch text is tied with the corresponding revision number. This helps adding templater support. IIRC, the pbranch extension doesn't work with the recent Mercurial versions, so the removal of this option wouldn't hurt.

patchbomb: factor out function that builds a prefix string to patch subject I'll add templating support.

formatter: add argument to change output file of non-plain formatter This allows us to build data not written to the console. That would be doable by ui.pushbuffer()/popbuffer(), but changing the file object seems cleaner.

schemes: move re construction to module-level and python3-ify This makes the schemes extension load correctly in Python 3.

dispatch: cope with sys.version being unicode on Python 3

dispatch: allow testedwith to be bytes or str

ui: fix ui.traceback on Python 3

ui: fix opts labeling on ui.warn et al for Python 3 This is a step towards fixing extension load warnings on Python 3. Note that I suspect there are still some bugs in this area and that things like color won't work, but the code at least executes and prints text to the console correctly now.

config: add sanity assert that files are opened as binary This helps with some debugging in Python 3, and shouldn't hurt anything in Python 2. The unusual construction using getattr is done so that StringIO/BytesIO instances can be used as well as real files.

update: for "noconflict" updates, print "conflicting changes" on conflict With experimental.updatecheck=noconflict, if the update is aborted because of conlicts, "uncommitted changes" is not quite accurate. Let's use "conflicting changes" instead. Also fix the hint to recomment --clean, not --merge, since that's what we do for other failed updates.

tests: fix test-update-branches to remove non-conflicting file I was clearly very sloppy when I wrote the test case for experimental.updatecheck=noconflict. The test case that checks that one can move between commits with a removed file was deleting a file that was modified between the source and target commits, which resulted in a "change/delete" conflict. Since that is a conlict, the update correctly failed. Let's fix the test by removing a file that is not modified between the two commits.

branches: populate all template keywords in formatter This is a usage example of fm.context().

formatter: add support for changeset templating Some formatter-based commands provide fields that are identical to the ones defined in templatekw, but we had to specify them manually to support all changeset-based template keywords. This patch adds fm.context() that populates all templatekw. These keywords are available only in template output, so we still need to set important keywords via fm.data() if they should be available in e.g. JSON output. Currently fm.context() takes only 'ctx' argument. It will eventually be extended to take 'fctx' to support file-based keywords (e.g. {path}) seen in hgweb.

templatekw: move defaulttmpl constant from changeset_templater These templates are used when rendering inner lists of some template keywords, so it makes sense to define them in templatekw. This allows us to reuse them to create a templateformatter knowing changectx.

formatter: drop filters argument from maketemplater() It's unused now. I want to keep the high-level API simple.

templater: port formatnode filter from changeset_templater This slightly reduces the difference between changeset_templater and formatter, and helps extending formatter to support changeset templating. New formatnode() is not a template filter, but a function since a filter cannot access to ui. And it's marked as DEPRECATED since I think it exists only for compatibility reasons.

update: allow setting default update check to "noconflict" The new value allows update (linear or not) as long as they don't result in file merges. I'm hoping that this value can some day become the default.

update: add experimental config for default way of handling dirty wdir This allows the user to set e.g. experimental.updatecheck=abort to abort update if the working directory is dirty, but still be able to override the behavior with e.g. --merge when needed. I considered adding a --mergelinear option to get back the old behavior even when experimental.updatecheck=abort is set, but I couldn't see why anyone would prefer that over --merge. The default is read in hg.updatetotally(), which means it also applies to "hg pull -u" and "hg unbundle -u".

update: accept --merge to allow merging across topo branches (issue5125)

merge: combine the "merge" cases in docstring table

merge: combine "dirty" cases in docstring table

merge: clarify non-linear default updates in docstring table Non-linear updates won't happen by default, regardless of -c/-C.

merge: combine the two "can't happen" cases in docstring table

merge: move "incompatible options" case first in docstring table

merge: make "linear" an input in docstring table Instead of having two ouputs, it seem simpler to have an addition input. This will allow further simplification.

merge: drop redundant column in docstring table The "same" and "cross" columns now have the same values, so let's combine them into "non-linear".

merge: drop obsolete non-linear cases from docstring table Since 6b1fc09c699a (update: change default destination to tipmost descendant (issue4673) (BC), 2016-02-02), non-linear updates can no longer happen if the user doesn't specify a destination, so we can drop these case from the table in the docstring of merge.update().

revert: move code dealing with deletions closer together

ui: fix configlist on Python 3 Since we're working on bytestrings, we have to use [offset:offset+1] to get consistent behavior on Python 2 and 3. I've only tested the _parse_plain closure, not the _parse_quote one, but I have no real reason to expect the latter to be broken since the fixes were fairly mechanical.

config: pass some optional args as keywords This makes it a little more obvious that self.read is being passed as include, which took me a moment to figure out.

config: load included config files in binary mode I guess we've been getting lucky that this works in Python 2. This fixes loading included config files in Python 3 (it used to fail on the "somebody set up us the BOM" check.)

manifest: remove _repo from manifestctx objects We were storing the repo on the manifestctx objects so that they could access the manifestlog via repo.manifestlog, which would refresh the structure if it became out of date. This caused probems however when we want to have multiple manifest logs in memory at once, like when transitioning to tree manifest from flat manifests, since a tree manifest would try to access sub-trees via repo.manifestlog[node], which was the flat manifest. The solution is to just not store the repo, and instead store the manifestlog that created this context. This removes the invalidation when the in memory manifestlog becomes out of date, but people should probably not be keeping ctx's around that long anyway.

phases: remove experimental.nativephaseskillswitch The native code has been used for a long time. Therefore drop the experimental config option.

manifest: allow specifying the revlog filename Previously we had hardcoded the manifest filename to be 00manifest.i. In our external treemanifest extension, we want to allow writing a treemanifest side by side with a flat manifest, so we need to be able to store the root revisions at a different location (in our extension we use 00manifesttree.i). This patches moves the revlog name to a parameter so we can adjust it.

py3: drop unrequired code from __init__.py Once we are using pycompat.open(), we don't need this hack to convert the second argument to unicodes. So removing this.

py3: add pycompat.open and replace open() calls open() requires mode argument as unicodes on Python 3. This patch introduces pycompat.open() which is inserted to files using transformer and replaces builtins.open() calls.

localrepo: deprecate 'repo.opener' (API) The "new" 'repo.vfs' attribute have been around for almost 5 years. I think we can deprecate the old form now ;-)

statichttp: use 'repo.vfs' as the main attribute We are about to deprecate the repo.opener attribute, we prepare the static http code to be ready for this change.

clonebundle: use 'repo.vfs' instead of 'repo.opener' The later is a 5 years old form.

localrepo: deprecated 'repo.wopener' (API) The "new" 'repo.wvfs' attribute have been around for almost 5 years. I think we can deprecate the old form now ;-)

localrepo: add some comment about role of various vfs object This should make things clearer for most people.

tests: un-nest the `order` repo in test-rebase-scenario-global This wasn't hurting anything, but it's more in line with how we manage other tests.

osx: install bash and zsh completions by default The zsh location appears to be on the default $fpath for zsh. bash, on the other hand, appears to have no default location for completion scripts, so we follow the lead of Apple's Git distribution and select a semi-arbitrary place in /usr/local for the file.

util: add allowhardlinks module variable To enable extensions to enable hardlinks for certain environments, let's move the 'if False' to be an 'if allowhardlinks' and let extensions modify the allowhardlinks variable. Tests on linux ext4 pass with it set to True and to False.

merge with stable

revert: remove set(mf) because it's O(manifest) The revert code had a 'set(manifest)' line in it, which has a runtime equivalent to the size of the manifest. With alternative manifest implementations, like treemanifest, this can be extra expensive. Let's rewrite it to be O(changes) instead of O(manifest size).

share: add --relative flag to store a relative path to the source Storing a relative path the source repository is useful when exporting repositories over the network or when they're located on external drives where the mountpoint isn't always fixed. Currently, Mercurial interprets paths in `.hg/shared` relative to $PWD. I suspect this is very much unintentional, and you have to manually edit `.hg/shared` in order to trigger this behaviour. However, on the off chance that someone might rely on it, I added a new capability called 'relshared'. In addition, this makes earlier versions of Mercurial fail with a graceful error. I should note that I haven't tested this patch on Windows.

minirst: support passing admonitions into findadmonitions() and parse() This will allow consumers to declare a custom list of admonitions to parse. Without this patch, custom admonitions would get removed when prunecomments() is run. We could add an argument controlling whether prunecomments() is run. However, it is better to convert the "paragraph" block to an "admonition" block so consumers don't have to parse for custom admonitions.

minirst: dynamically compile admonitions regexp Currently, parsing admonitions uses a static regular expression created from a pre-defined list of admonitions. A future patch will introduce a feature that needs to parse custom admonitions. Prepare for this by compiling the admonitions regular expression during each function invocation. Strictly speaking, there is a slight performance loss here. But we only run this code as part of displaying help text. I don't think the loss will be noticeable and I don't think we care if it were.

minirst: detect bullet lists using asterisks Previously, the "bullet" regular expression excluded the asterisk ('*') as a character denoting a bulleted list. Why I'm not sure because the asterisk seems to be the canonical bullet character in reST these days. This patch makes asterisk-prefixed lines parse as bulleted lists.

color: update the help table We also need to reference the new topic in the great old help table.

ui: remove superfluous indent in _write()

smartset: reorder initialization of baseset in more intuitive way What we want to do is to assign either _set or _list per the given data type.

config: update the Windows example config file We move from the color extensions to the 'ui.color' config.

help: use 'churn' instead of 'color' as an example extension The 'color' extensions is now deprecated.

config: suggest the 'ui.color' instead of the 'color' extension The extensions is deprecated now so we should offer the core way to handle color instead.

color: update main documentation Now that the feature no longer lives in the extension, we document it in the help of the core config. This include the new 'ui.color' option introduced in the previous changesets. As a result the color extensions can now be deprecated. This is a documentation patch only; color is still disabled by default.

pager: drop the 'color' dependant code The 'color' implementation is in core and no longer wrap '_runcommand'. We drop the extra complexity.

color: cleanup 'debugcolor' logic Now that style are carried by the 'ui' object, we no longer need complicated logic to restore the original style. We just need to copy the 'ui' and work on the copied version.

color: move 'debugcolor' into the 'debugcommands' modules This is the last bits we needed to move out of the extensions. 'hgext/color.py' now only contains logic to changes the default color behavior to 'auto'. However, more cleanups are on the way and we need to document the new config directly in core.

merge with stable

color: rename '_styles' to '_defaultstyles' for clarity This should make it clear the dict is only used for new config. Extensions should not modify it directly anyway since we have 'extraloader' logic for loading '_styles' too.

color: move 'styles' definition on the 'ui' object Same logic as for '_terminfoparams'. The content depends on the config so it should be specific to each 'ui instance.

color: pass 'ui' to 'win32print' Same logic as before,'win32print' relies on some data we will move on the 'ui' object soon, we update the API beforehand for clarity.

color: move the dict with terminfo parameters on the ui object This dictionnary is affected by the content of the config, so we should have one for each ui config. We rename the global dict to '_baseterminfoparams' to make the situation clearer.

color: add ui to effect rendering We'll carry more and more color specific data on the ui object. This will help isolating different color configuration from each other. For example repository config might configure special style that should not affect other ui object. The first step is to make sure the ui object is available were we will needs it.

color: initialize color for the localrepo ui The 'ui' object dedicated to a 'localrepo' is independent from the one available in dispatch (and 'uisetup'). In addition, it is created from the 'baseui' (apparently for good reason). As a result, we need to run the color setup on it after the local repository config is read. This was overlooked when the rest of the initialization changed but did not had impact yet because all setup is still global. We fix it before it is too late.

color: add a 'ui.color' option to control color behavior This new option control whether or not color will be used. It mirror the behavior of '--color'. I usually avoid adding new option to '[ui]' as the section is already filled with many option. However, I feel like 'color' is central enough to deserves a spot in this '[ui]' section. For now the option is not documented so it is still marked as experimental. Once it get documented and official, we should be able to deprecate the color extensions. There is more cleanup to do before that documentation is written, but we need this option early to made them. Having that option will allow for more cleanup of the initialisation process and proper separation between color configuration.

color: reinvent dictionary move the module lever dictionary declaration to a more standard (and practical indentation)

chg: deduplicate error handling of ui.system() This moves 'onerr' handling from low-level util.system() to higher level, which seems better API separation.

chg: refactor ui.system() to be partly overridden Since fd598149112b changed the signature of ui.system(), chgui.system() should have been updated. This patch factors out the util.system() call so that chg can override how a shell command is executed.

color: have the 'ui' object carry the '_colormode' directly Before this changeset, the value was carried by the class to work around limitation of the extensions initialisation. Now that the initialisation is cleanly handled in 'dispatch', we can drop this work around.

color: move triggering of the initialisation logic in core We now run the color initialisation as part of the standard dispatch. This is opening the way for multiple cleanups since we now have access to the multiple 'ui' object and we'll be able to see difference between global and local config. This cleanup will arrive in later changesets. As a side effect, the '--color' flag is now working without the extension. Since we now properly initialize color for each ui idependently, we get a warning message twice.

color: add the definition of '--color' in core If we want to be able to move the initialisation in core, we need core to be aware of that '--color' flag at all time. So we now have the definition in core. That flag is currently unprocessed without the extensions (will be fixed soon). In addition the default value for this flag in core is 'never'. Enabling the extensions change that default value to 'auto'.

color: handle 'ui.plain()' directly in mode setup If 'ui.plain()' is set we should not colorize. We move that logic into the function that determine and setup the color mode. As all other code respect the resulting mode this will be equivalent.

color: move git-subrepo support into the subrepo module Now that all ui instance carry a '_colormode' attribute, we can access and comply to it directly in the subrepo code. The actual implementation could probably be a bit smarter, but we stick close to the current one for the sake of simplicity.

color: move 'modesetup' into the core module Yet another piece of code moving from the extensions to the module in core!

color: move 'terminfosetup' into the core module Another step closer to have all the logic living in core

subrepo: run the repo decoders when archiving The decoders were already run by default for the main repo, so this seemed like an oversight. The extdiff extension has been using 'archive' since 68822b7cdd01 to support -S, and a colleague noticed that after diffing, making changes, and closing it, the line endings were wrong for the diff-tool modified files in the subrepository. (Files in the parent repo were correct, with the same .hgeol settings.) The editor (Visual Studio in this case) reloads the file, but doesn't notice the EOL change. It still adds new lines with the original EOL setting, and the file ends up inconsistent. Without this change, the first file `cat`d in the test prints '\r (esc)' EOL, but the second doesn't on Windows or Linux.

wix: include the help for pager Similar (I assume) to 65d2538ac993.

manifest: check 'if x is None' instead of 'if not x' The old code here would end up executing __len__ on a tree manifest to determine if 'not _data' was true or not. This was very expensive on large repos. Since this function just cares about memoization, we can just check 'if _data is None' instead and save a bunch of time.

pager: add support to --patch, --list and --stat options of hg shelve

color: drop the 'colorui' class Now that all logics formally bared by 'colorui' have been moved to the main ui class, that class is empty and can be dropped. As a nice side effect we can get rid of the baroque Initialization associated to it. There was much rejoicing.

color: move 'write-err' logic to the core ui class This is similar to what we needed for 'write', we move the logic from the extension to the core class. Beside the dispatch to 'win32print', we just apply label to the argument.

ui: extract low level part of 'write_err' in its own method Same as for 'write' and '_write' we needs it available for some of the color logic.

ui: extract buffer write from protect and timed 'write_err' output That subcall to 'self.write' is never doing actual write but only store things in buffers. So we do not need to protect it for exception not to time its execution. This will make it easier to extract a '_write_err' function as we did for 'write'.

color: move 'write' logic to the core ui class One more step, the support for writing color is not directly in core. No behavior change for the default case ('_colormode' = None). Here are the details of what we have to change to the core method: * apply to 'self.label' to input in the buffered case * dispatch to 'win32print' when applicable * apply to 'self.label' to input when applicable

ui: extract the low level part of 'write' in a dedicated function We are about to add some extra logic related to color. That logic will need to access the low level layer of ui doing the actual write to a stream. (eg: 'win32print'). We extract this logic into a private method for this purpose.

color: add multiple messages input support to 'win32print' All other function doing writes support any number of input message. For simplicity, we make 'win32print' able to do the same.

color: clarify name of an argument of 'win32print' In the current code, the function called to write happens to the 'orig' version of the method calling 'win32print' (obtained with a 'super' call). However, the variable could have a better name. That will be useful when we'll stop having inheritance in play.

color: move the 'colorlabel' call to the core 'ui' class This bring us closer to supporting color in core natively. Core already have a 'label' method that was a no-op. We update its to call the new 'colorlabel' function. Behavior is unchanged when colormode = None.

color: move the 'colorlabel' function in the core module The extract code is relocated in core.

color: extract the label code into its own function We extract the logic into a function. This will allow us to move the logic into the core 'color' module and later call it directly from core.

color: inline the 'showlabel' method This function is quite simple and only have one call site… located a handful of line under the definition. We inline the function for the sake of simplicity. One of the motivation to do that now is that it reduce the amount of new method we will have to add to the core 'ui' class for color support.

color: move '_colormode' to the core 'ui' class Having all 'ui' objects aware of 'color' allows us to update the core code to handle color. The mode will stay 'None' in the default case so that will not introduce any changes.

hgweb: explictly pass basectx in webutil.diffs There's only one case where `basectx` parameter is None (over two usages), so it's probably not worth handling the special case as it makes code-reading harder. Along the way, use ctx.p1() instead of checking for ctx.parents() being empty which should not occur.

serve: mark --stdio and --cmdserver as "(ADVANCED)" flags This will hide them from the default --help output.

help: hide command line options marked as "advanced" Previously, we have keywords like "(DEPRECATED)" and "(EXPERIMENTAL)" to hide command line options in non-verbose help output. However, sometimes an option is neither deprecated nor experimental. It's well-tested and working, but just not designed to average users. This patch adds a keyword "(ADVANCED)" to fit in such use cases. Thanks rom1dep for the suggestion of the word "advanced".

pager: do not try to run an empty pager command If pagercmd is explicitly set to '', the pager process would exit silently and the output would be lost. We'd better disable the pager in such case.

graphlog: restore pager lost at 1cec1d863008

gitweb: add "more" and "less" navigation links in filelog template

context: also return ancestor's line range in blockancestors

context: add a followfirst flag to blockancestors

py3: use pycompat.fsencode() to convert __file__ to bytes __file__ returns unicodes on Python 3. This patch uses pycompat.fsencode() to convert them to bytes.

wireproto: remove unused code Removed an unused line introduced by f3807a135e43.

color: set initial default value for 'colormode' to None This should not introduce any behavior changes when using the color extension. In practive, the colormode will be setup at early at run time to the proper value (from config and environment). We do this change as this gets us closer of a state were we can have all the mechanisms associated to color in core with the feature disabled by default.

color: minor reversal of two conditional clause for clarity Another minor cleanup while reading the code. The two branches of the conditional have similar complexity so we go for the order that give us the simplest condition (we drop the negation).

color: merge two identical 'for' loops The previous changeset made it clear that we are iterating twice on the same items. We gather the two loops into a single one.

color: minor simplification of some terminfo setup code No logic change is introduced. The previous code were using a 'dict.update' with a complex generator. That was a bit confusing to read and not so compact. Instead we now use an explicit loop and conditional for the sake of clarity. This also allow for more simplification coming in the next changeset.

color: make a test for curse availability explicite We won't use terminfo when curse failed to load. Before this change, we were doing an indirect test, relying on the fact some variable ('_terminfo_params') would be empty if curses failed to load. We update the code to be more explicit and directly checks if we managed to load the curse module.

color: move 'win32' declaration to the core module This is another part of moving color implementation into core. before we can move the advance logic, we need to move the basic definition and building bricks. This is one more step on that road.

smartset: preserve istopo for baseset operations This is a follow-up of "smartset: use native set operations as fast paths". It's more correct to just preserve the "istopo" information for "&" and "-" operations, like what filteredset does.

pager: add a config knob to just globally turn off the pager

pager: move most help to a new help topic and deprecate extension

dispatch: rearrange 'unknown command' code to better employ pager dispatch calls help like a ninja if you give it a truly unknown command, and that might want to be paged. If it gets paged, then the 'hg: unknown command' text gets eaten by a grue, unless we call the pager first. This change rearranges the codepaths so we can safely only invoke the pager in the case where we'll have long output from the help command code, rather than just a short message like "did you mean stat instead of start" or "fetch is provided by the fetch extension".

help: move rst formatting of help documents into help.py This slight refactor will help me improve the 'unknown command' experience in our new glorious pager future.

outgoing: avoid running pager until we're actually showing changes Consistent with the new behavior of incoming in the previous patch.

incoming: delay pager activation until right before printing changes This prevents authentication and other brief status messages from being paged.

histedit: modify rollup to discard date from the rollup commit (issue4820) This change adjusts and documents the new behaviour of 'roll'. It now fits nicely with the behaviour of 'commit --amend' and the 'edit' action, by discarding the date as well as the commit message of the second commit. Previously it used the later date, like 'fold', but this often wasn't desirable, for example, in the common use case of using 'roll' to add forgotten changes to a changeset (because 'hg add' was previously forgotten or not all changes were identified while using 'hg record').

histedit: improve documentation and behaviour of dates This clarifies in the histedit documentation that the 'edit' action preserves the date and that the 'fold' action uses the later date. The documentation was previously silent on this issue which left users in doubt.