vfs: add a 'reljoin' function for joining relative paths The vfs.join method only works for absolute paths. We need something that works for relative paths too when transforming filenames. Since os.path.join may misbehave in tricky encoding situations, encapsulate the new join method in our vfs abstraction. The default implementation remains os.path.join, but this opens the door to other VFSes doing something more intelligent based on their needs. In the same go, we replace the usage of 'os.path.join' in transaction code.

subrepo: fix git subrepo ui argument

subrepo: drop the 'ui' parameter to revert() This no longer needs to be explicitly passed because the subrepo object tracks the 'ui' reference since fcbc66b5da6a. See the change to 'archive' for details about the differences between the output level in the root repo and subrepo 'ui' object. The only use for 'ui' in revert is to emit status and warning messages, and to check the verbose flag prior to printing the action to be performed on a file. The local repo's ui was already being used to print a warning message in wctx.forget() and for 'ui.slash' when walking dirstate in the repo.status() call. Unlike other methods where the matcher is passed along and narrowed, a new matcher is created in each repo, and therefore the bad() method already used the local repo's ui.

subrepo: drop the 'ui' parameter to removefiles() This no longer needs to be explicitly passed because the subrepo object tracks the 'ui' reference since fcbc66b5da6a. See the change to 'archive' for details about the differences between the output level in the root repo and subrepo 'ui' object. The only use for 'ui' in remove is to emit status and warning messages, and to check the verbose flag prior to printing files to be removed. The bad() method on the matcher still uses the root repo's ui, because narrowing the matcher doesn't change the ui object. The local repo's ui was already being used to print a warning message in wctx.forget() and for 'ui.slash' when walking dirstate in the repo.status() call.

subrepo: drop the 'ui' parameter to forget() This no longer needs to be explicitly passed because the subrepo object tracks the 'ui' reference since fcbc66b5da6a. See the change to 'archive' for details about the differences between the output level in the root repo and subrepo 'ui' object. The only use for 'ui' in forget is to emit status and warning messages, and to check the verbose flag prior to printing files to be forgotten. The bad() method on the matcher still uses the root repo's ui, because narrowing the matcher doesn't change the ui object. The local repo's ui was already being used to print a warning message in wctx.forget() and for 'ui.slash' when walking dirstate in the repo.status() call.

subrepo: drop the 'ui' parameter to cat() This no longer needs to be explicitly passed because the subrepo object tracks a 'ui' reference since fcbc66b5da6a. See the change to 'archive' for details about the differences between the output level in the root repo and subrepo 'ui' object. The only use for 'ui' in cat is to emit a status message when a subrepo is missing. The bad() method on the matcher still uses the root repo's ui, because narrowing the matcher doesn't change the ui object.

subrepo: drop the 'ui' parameter to archive() The current state of subrepo methods is to pass a 'ui' object to some methods, which has the effect of overriding the subrepo configuration since it is the root repo's 'ui' that is passed along as deep as there are subrepos. Other subrepo method are *not* passed the root 'ui', and instead delegate to their repo object's 'ui'. Even in the former case where the root 'ui' is available, some methods are inconsistent in their use of both the root 'ui' and the local repo's 'ui'. (Consider hg._incoming() uses the root 'ui' for path expansion and some status messages, but also calls bundlerepo.getremotechanges(), which eventually calls discovery.findcommonincoming(), which calls setdiscovery.findcommonheads(), which calls status() on the local repo 'ui'.) This inconsistency with respect to the configured output level is probably always hidden, because --verbose, --debug and --quiet, along with their 'ui.xxx' equivalents in the global and user level hgrc files are propagated from the parent repo to the subrepo via 'baseui'. The 'ui.xxx' settings in the parent repo hgrc file are not propagated, but that seems like an unusual thing to set on a per repo config file. Any 'ui.xxx' options changed by --config are also not propagated, because they are set on repo.ui by dispatch.py, not repo.baseui. The goal here is to cleanup the subrepo methods by dropping the 'ui' parameter, which in turn prevents mixing subtly different 'ui' instances on a given subrepo level. Some methods use more than just the output level settings in 'ui' (add for example ends up calling scmutil.checkportabilityalert() with both the root and local repo's 'ui' at different points). This series just goes for the low hanging fruit and switches methods that only use the output level. If we really care about not letting a subrepo config override the root repo's output level, we can propagate the verbose, debug and quiet settings to the subrepo in the same way 'ui.commitsubrepos' is in hgsubrepo.__init__. Archive only uses the 'ui' object to call its progress() method, and gitsubrepo calls status().

subrepo: use 'self.ui' instead of 'self._repo.ui' They are now equivalent, but the former is slightly more readable.

subrepo: reset 'self.ui' to the subrepo copy of 'ui' in the hgsubrepo class Creation of the subrepo's '_repo' object creates a new 'ui' by combining the parent repo's 'baseui' and reading in the subrepo's hgrc file. This simply avoids 'self.ui' and 'self._repo.ui' pointing to different objects, which seems like a potential source of bugs. Git and Svn subrepos are unchanged, because they don't have their own ui, and have always used their parent's for their configuration.

subrepo: rename the '_ui' member to 'ui' The localrepository class has a 'ui' member, so keeping the names the same will allow for duck typing with subrepo instances when accessing 'ui'. Changing this is easier than finding all of the localrepository instance uses and renaming that to '_ui'.

subrepo: drop the '_ui' member in the subrepo subclasses This member has existed in the base class since fcbc66b5da6a.

graphmod: attempt to clarify documentation of groupbranchiter() Thanks to Pierre-Yves for checking my cleanups here and helping me understand the algorithm well enough to help document it.

graphmod: rename graph-topological config to graph-group-branches The latter suggests what the change is slightly better.

groupbranchiter: allow callers to select the first branch Instead of just bootstrapping the algorithm with the first revision we see, allow callers to pass revs that should be displayed first. All branches are retained until we can display such revision. Expected usage is to display the current working copy parent first.

groupbranchiter: support for non-contiguous revsets The algorithm now works when some revisions are skipped. We now use "first included ancestors" instead of just "parent" to link changesets with each other.

groubranchhiter: indent most of the inner code We are going to add an additional layer of indentation to support non-contiguous revset. We do it in a pure code movement changeset to help the readability of the next changeset.

graphlog: add a way to test the 'groupbranchiter' function We add an experimental config option to use the topological sorting. I first tried to hook the 'groupbranchiter' function in the 'sort' revset but this was useless because graphlog enforces revision number sorting :( As the goal is to advance on the topological iteration logic, I see this experimental option as a good way to move forward. We have to use turn the iterator into a list because the graphlog is apparently not ready for pure iterator input yet.

graphmod: add a function for topological iteration This changeset introduces a function to perform topological (one branch after the other) iteration over a set of changesets. This first version has a lot of limitations, but the approach should be flexible enough to allow many improvements in the future. This changeset aims to set the first stone more than providing a complete solution. The algorithm does not need to know the whole set of nodes involved before emitting revision. This makes it a good candidate for usage in place like `hg log` or graphical tools that need a fast first result time.

namespaces: add branches Note that the exception-catching from the previous branchtip check is moved up to catch exceptions from the try block surrounding the namespace lookup.

namespaces: add tags

namespaces: remove weakref; always pass in repo It turns out that maintaining a reference of any sort (even weak!) to the repo when constructed doesn't work because we may at some point pass in a repoview filtered by something other than what the initial repo was.

changectx: use names api to simplify and extend node lookup Previously, changectx had to know about each type of name (bookmark, tag, etc.) to look up. Now, we use repo.namenodes to simplify (and extend) this.

namespaces: add a method to the first matching node for a given name

namespaces: add bookmarks to the names data structure This marks the first use of abstracting our different types of named objects (bookmarks, tags, branches, etc.) and upcoming patches will use this to simplify logic.

namespaces: add a convenience property for the weakref _repo

namespaces: pass repo to __init__ We store repo as a weakref so that we can prevent a cycle between namespaces and localrepo.

namespaces: add a function to turn single results into lists

namespaces: add a method to register new namespaces

namespaces: introduce a generic way to map between names and nodes This patch begins the work to provide a way to register a namespace to handle 'names'. Benefits of this would be, - improved templating: This would provide {name} which could output any branch, bookmark, tag, or any extension registered namespace all without having the extension doing any extra work - improved tab completion: Since this provides a single source of all 'names', tab completion would not need to know of each namespace - changeset lookup: Similar to before, a unified place to get all 'names' will allow finding changesets without any extension code having to reimplement this Also, d226fe36e362 has shown us that for internal code which expects a certain type of method or behavior, we should provide an easy way for extensions to check this behavior.

statichttprepo: update profile of __call__ in mock vfs object New code paths could fail because the old statichttprepo profile couldn't handle the usual parameters. Instead, reuse a more generic profile also used in readonlyvfs.

tests: avoid git diffstat singular/plural output difference 'git diff --stat' output changed with regard to the amount of changes/insertions/deletions shown. In older git versions (1.7.7.6), output was shown as: 2 files changed, 2 insertions(+), 1 deletions(-) In newer versions, output is shown as: 2 files changed, 2 insertions(+), 1 deletion(-) This patch uses a regex to handle both cases.

subrepo: add revert support without backup for git subrepos Previously, git subrepos did not support reverting. This change adds basic support for reverting when '--no-backup' is specified. A warning is given (and the current state is kept) when a revert is done without the '--no-backup' flag.

match: make 'always' and 'exact' functions, not classes There is no reason for classes 'always' and 'exact' not to be just functions that return instances the plain 'match' class.

share: implement shared bookmark functionality This does not cause any behavioral change unless a 'bookmarks.shared' marker file exists. A future change will add UI to create this file when a repository is shared.

debugindex: respect --debug flag to show full nodeids

localrepo.clone: add a way to override server preferuncompressed Without this patch, if the server sets preferuncompressed, there's no way for clients to override that and force a non-streaming clone. With this patch, we extend the meaning of --pull to also override preferuncompressed and force a non-streaming clone.

hg.clone: set 'stream' depending on whether --pull was requested or not In an upcoming patch we'll differentiate between the two in localrepo.

merge: perform case-collision checking on final set of actions When there are multiple common ancestors, we should check for case collisions only on the resulting actions after bid merge has run. To do this, move the code until after bid merge. Move it past _resolvetrivial() too, since that might update actions. If the remote changed a file and then reverted the change, while the local side deleted the file and created a new file with a name that case-folds like the old file, we should fail before this patch but not after. Although the changes to the actions caused by _forgetremoved() should have no effect on case collisions, move it after that, too, so the next person reading the code won't have to think about it. Moving it past these blocks of code takes it to the end of calculateupdates(), so let's even move it outside of the method, so we also check collisions in actions produced by extensions overriding the method.

spelling: fixes from proofreading of spell checker issues

tests: allow more flexibility in git diffstat output The output of 'git diff --stat' changed in git 1.7.10 and 1.7.11. To ensure the tests work with earlier versions of git as well, the output is now wrapped with a whitespace regex.

merge: move cd/dc prompts after largefiles prompts By moving the cd/dc prompts out of calculateupdates(), we let largefiles' overridecalculateupdates() so the unresolved values (i.e. 'cd' or 'dc' rather than 'g', 'r', 'a' and missing). This allows overridecalculateupdates() to ask the user whether to keep the normal file or the largefile before the user gets the cd/dc prompt. Whichever answer the user gives, we make overridecalculateupdates() replace 'cd' or 'dc' action, saving the user one annoying (and less clear) question.

addremove: automatically process a subrepository's subrepos Since addremove on the top of a directory tree will recursively handle sub directories, it should be the same with deep subrepos, once the user has explicitly asked to process a subrepo. This really only has an effect when a path that is a subrepo (or is in a subrepo) is given, since -S causes all subrepos to be processed already. An addremove without a path that crosses into a subrepo, will still not enter any subrepos, per backward compatibility rules.

addremove: support addremove with explicit paths in subrepos Git and svn subrepos are currently not supported.

addremove: add support for the -S flag Git and svn subrepos are currently not supported. It doesn't look like git or svn have these commands natively, so that's an area for a git or svn expert.

commit: propagate --addremove to subrepos if -S is specified (issue3759) The recursive addremove operation occurs completely before the first subrepo is committed. Only hg subrepos support the addremove operation at the moment- svn and git subrepos will warn and abort the commit.

subrepo: store the ui object in the base class This will be used in the next patch to print a warning from the base class. It seems better than having to explicitly pass it to a new method, since a lot of existing methods also require it.

commit: abort if --addremove is specified, but fails This will be required when subrepo support is added, in order to ensure consistent commits when a subrepo flavor doesn't support addremove.

addremove: warn when addremove fails to operate on a named path It looks like a bad path is the only mode of failure for addremove. This warning is probably useful for the standalone command, but more important for 'commit -A'. That command doesn't currently abort if the addremove fails, but it will be made to do so prior to adding subrepo support, since not all subrepos will support addremove. We could just abort here, but it looks like addremove has always silently ignored bad paths, except for the exit code.

scmutil: pass a matcher to scmutil.addremove() instead of a list of patterns This will make it easier to support subrepository operations.

tests: fix a typo in test-walkrepos.py

merge: extract _resolvetrivial() function We would eventually like to move the resolution of modify/delete and delete/modify conflicts to the resolve phase. However, we don't want to move the checks for identical content that were added in 902554884335 (merge: before cd/dc prompt, check that changed side really changed, 2014-12-01). Let's instead move these out to a new _resolvetrivial() function that processes the actions from manifestmerge() and replaces any false cd/dc conflicts. The function will also provide a natural place for us to later add code for resolving false 'm' conflicts.

largefiles: start by finding files of interest Instead of iterating over 'g' action, first find the set of all files that are largefiles in p1. Then iterate over these files. This prepares for considering actions other than 'g'.

largefiles: rewrite merge code using dictionary with entry per file In overridecalculateupdates(), we currently only deal with conflicts that result in a 'g' action for either the largefile or a standin. We will soon want to deal cases with 'cd' and 'dc' actions here. It will be easier to reason about such cases if we rewrite it using a dict from filename to action. A side-effect of this change is that the output can only have one action per file (which should be a good change). Before this change, when one of the tests in test-issue3084 received this input (the 'a' in the input was a result of 'cd' conflict resolved in favor of the modified file): 'g': [('.hglf/f', ('',), 'remote created')], 'a': [('f', None, 'prompt keep')], and the user chose to keep the local largefile, it produced this output: 'g': [('.hglf/f', ('',), 'remote created')], 'r': [('f', None, 'replaced by standin')], 'a': [('f', None, 'prompt keep')], Although 'a' actions are processed after 'r' actions by recordupdates(), it still worked because 'a' actions have no effect on merges (only on updates). After this change, the output is: 'g': [('.hglf/f', ('',), 'remote created')], 'r': [('f', None, 'replaced by standin')], Similarly, there are several tests in test-largefiles-update that get inputs like: 'a': [('.hglf/large2', None, 'prompt keep')], 'g': [('large2', ('',), 'remote created')], and when the user chooses to keep the local largefile, they produce this output: 'a': [('.hglf/large2', None, 'prompt keep'), ('.hglf/large2', None, 'keep standin')], 'lfmr': [('large2', None, 'forget non-standin largefile')], In this case, it was not a merge but an update, so the 'a' action does have an effect. However, since dirstate.add() is idempotent, it still has no obserable effect. After this change, the output is: 'a': [('.hglf/large2', None, 'keep standin')], 'lfmr': [('large2', None, 'forget non-standin largefile')],

largefiles: put same 'action' object back in 'newglist' The items we put in 'newglist' are always the same as what we found in actions['g'], so let's just put the same item into the list instead of creating a new one.

largefiles: don't unnecessarily sort merge action lists The action lists returned from calculateupdates() (in merge.py) are not required to be sorted. In fact, since they result from iteration over the unordered manifest, they are unlikely to be sorted. Moreover, some of the lists are appended to after they are returned from manifestmerge(). The lists are instead sorted in applyupdates(). Therefore, let's not sort the lists generated in largefiles' overridecalculateupdates().

merge: don't treat 'diverge' and 'renamedelete' like actions See earlier patch for motivation.

merge: move dr/rd warning messages out of applyupdates() As preparation for making 'dr' and 'rd' actions no longer actions, move the reporting from applyupdates() to its caller update(). This way we won't have to pass additonal arguments to applyupdates() when they are no longer actions. Also, the warnings are equally unrelated to applyupdates() as they are to recordupdates(), as they don't result in any changes to either the working copy or the dirstate. See earlier patch for additional motivation.

merge: don't report progress for dr/rd actions It is easier to reason about certain algorithms in terms of a file->action mapping than the current action->list-of-files. Bid merge is already written this way (but with a list of actions per file), and largefiles' overridecalculateupdates() will also benefit. However, that requires us to have at most one action per file. That requirement is currently violated by 'dr' (divergent rename) and 'rd' (rename and delete) actions, which can exist for the same file as some other action. These actions are only used for displaying warnings to the user; they don't change anything in the working copy or the dirstate. In this way, they are similar to the 'k' (keep) action. However, they are even less action-like than 'k' is: 'k' at least describes what to do with the file ("do nothing"), while 'dr' and 'rd' or only annotations for files for which there may exist other, "real" actions. As a first step towards separating these acitons out, stop including them in the progress output, just like we already exclude the 'k' action.

subrepo: add partial diff support for git subrepos So far, git subrepositories were silently ignored for diffs. This patch adds support for git subrepositories, with the remark that --include and --exclude are not supported. If --include or --exclude are used, the subrepo is ignored.

subrepo: extend git version check to 3 digits This allows more flexibility when a version check is required. Some git features are introduced in a version where only the 3rd digit changes.

subrepo: move git version check into a separate method This allows checking the git version in other methods, instead of only being able to check if the version is ok or not.

rebase: show a note for updated mq patches It deserves more than a debug message. Show a note like: updating mq patch p0.patch to 5:9ecc820b1737 The message could also refer to "qrefresh" instead. Same same.

rebase: improve debug messages while processing the list of rebases

rebase: show warning when rebase creates no changes to commit Similar to graft: note: rebase of 6:eea13746799a created no changes to commit

rebase: show more useful status information while rebasing Show status messages while rebasing, similar to what graft do: rebasing 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.

tests: make 'saved backup' globbing less narrow in rebase tests Globbing the hash made it harder to maintain tests with run-tests -i when it was so far by the generated test output. The hashes are stable and we just need to add a (glob).

tests: stabilise mq rebase tests Prepare for including hashes in output ... and less globbing make the tests easier to update.

test-graft: use strip extension instead of mq extension It only needs strip, no reason to load all of mq.

transaction: remove the 'onabort' mechanism It has no known users. If someones needs similar functionality, a new 'addabort' method similar to 'addfinalize' should be added.

transaction: remove the redundant 'onclose' mechanism It is superseded by the 'addfinalize' function and all its user have been migrated.

fncache: document the fact fncache is outdate at hook run time Using 'addfinalize' to generate 'fncache' means that no pending version of the file will be generated for the hooks. We would have to use the 'addfilegenerator' method to get such result. However the 'fncachevfs' (who decide that a write is necessary) have no access to the transaction to register such file generation at add time. Having the transaction accessible to the 'vfs' is too much trouble for no benefit. This outdated 'fncache' file at hook time is not expected to be an issue. The previous move from 'onclose' to 'addfinalize' had no impact on this timing. I'm documenting it now because I looked at it.

fncache: drop dedicated 'onclose' function in favor of 'tr.addfinalize' Now that we have a shiny generic mechanism, we can use it.

merge with stable

graft: drop cset description from empty commit message This is either already redundant in the output or too verbose in quiet mode.

graft: show hashes in user-facing messages Graft was in various places just showing the revision number in status messges. Instead, also show the stable and more useful short hash.

graft: give helpful warning for empty grafts It was just showing a status message with the internal revision number. Instead, show a warning like note: graft of 27:3aaa8b6725f0 "28" created no changes to commit (message tweaked in-flight by mpm)

graft: show more useful status information while grafting Show status messages with first line of commit description and names, like grafting 12:2647734878ef "fork" (tip) This gives more context for the user when resolving conflicts.

tests: test coverage for empty graft A future change will add a warning to the quiet rebase.

largefiles: drop the unfiltered repo usage in overridepurge() Now that repoview supports replacing methods, we don't need this hack.

repoview: allow methods on the proxy class to be replaced It doesn't seem to be a common idiom for repo instances, but the status() method is replaced in largefiles' purge() override. Since __setattr__ is implemented in repoview to setattr() on the unfiltered repo, the replacement method wouldn't get called unless it was invoked with the unfiltered repo, because the filtered repo remains unchanged. Since this doesn't seem to be commonly used, I didn't bother to filter out methods that perhaps shouldn't be replaced, such as changelog().

log: fix log revset instability The log/graphlog revset was not producing stable results since it was iterating over a dict. Now we sort before iterating to guarantee a fixed order. This fixes some potential flakiness in the tests.

log: fix log -f slow path to actually follow history The revset created when -f was used with a slow path (for patterns and directories) did not actually contain any logic to enforce follow. Instead it was depending on the passed in subset to already be limited (which was limited to :. but not ::.). This fixes it by adding a '& ::.' to any -f log revset. hg log -f <file> is still broken, in that it can return results that aren't actually ancestors of the current file, but fixing that has major perf implications, so we'll deal with it later.

obsstore: cache size computation for fm1 node We have two different types of node type (sha1 and sha256, only sha1 is used now) and therefor different sizes for them. We now compute the value once instead of redoing the computation every loop. This has no visible performance impact.

obsstore: prefetch struct.calcsize This function is widely used and worth but be at module level. No specific performance boost is visible, but this is more consistent.

obsstore: disable garbage collection during initialization (issue4456) Python garbage collection is triggered by container creation. So code that creates a lot of tuples tends to trigger GC a lot. We disable the gc during obsolescence marker parsing and associated initialization. This provides an interesting speedup (25%). Load marker function on my 58758 markers repo: before: 0.468247 seconds after: 0.344362 seconds The benefit is a bit less visible overall. With python2.6 on my system I see: after: 0.60 before: 0.53 The difference is probably explained by the delaying of a costly GC. (but there is still a win). Marking involved tuples, lists and dicts as ignorable by the garbage collector should give us more benefit. But this is another adventure. Thanks goes to Siddharth Agarwal for the lead.

dirstate: use the 'nogc' decorator Now that we have a generic way to disable the gc, we use it. however, we have too use it in a baroque way. See inline comment for details.

util: add a 'nogc' decorator to disable the garbage collection Garbage collection behave pathologically when creating a lot of containers. As we do that more than once it become sensible to have a decorator for it. See inline documentation for details.

generate-working-copy-states: open() in binary mode when writing content This avoids changes to the hashes on Windows in test-merge-force.t like so: @@ -594,12 +594,12 @@ content2 M missing_content2_content3_content4-tracked - <<<<<<< local: 443153eb5b88 - test: local\r (esc) - content4 - ||||||| base - ======= - content2 - >>>>>>> other: 9b2ccd328a08 - test: remote\r (esc) + <<<<<<< local: 0447570f1af6 - test: local + content4 + ||||||| base + ======= + content2 + >>>>>>> other: 85100b8c675b - test: remote missing_content2_content3_content4-tracked.orig: content4

largefiles: don't use 'r' action for standin that doesn't exist When merging and the remote has turned a normal file into a largefile and the user chooses to keep the local largefile, we use the 'r' action for the remote largefile standin. This is wrong, since that file does not exist in the parent of the working copy. Use 'k', which does nothing but debug logging, instead.

largefiles: don't use 'r' action for normal file that doesn't exist When merging and the remote has turned a largefile into a normal file and the user chooses to keep the local largefile, we use the 'r' action for the remote normal file. This is wrong, since that file does not exist in the parent of the working copy. Use 'k', which does nothing but debug logging, instead.

rebase: handle revtodo as a special value when storing/restoring state Revtodo happens to share its value with nullrev, but this is an implementation details, so we move away from it. After this changeset one can successfully change the values for all the constants and the tests still pass, but doing so would require more refactoring if we want to avoid breaking backward compatibility on the state file.

rebase: add a 'revtodo' constant The state mapping is using '-1' to mark revisions that have not been rebased yet. We introduce and use a constant for that purpose. This will help emphasize the fact the value means something other than nullrev.

rebase: use '>= 0' to know is a revision was rebased The fact that the state for "not yet rebased" is -1 is an implementation details. So we change the comparisons to some semantically more correct.

patchbomb: introduce a 'patchbomb.confirm' option When set to true, this option will make patchbomb always ask for confirmation before sending the email. Confirmation is a powerful way to prevent stupid mistakes when the sending patches. This should let me get rid of my global alias adding --confirm to hg email. I know that some people may get bitten when moving from a machine with confirm configured to a machine where it is not, but I think it is worth the risk.

patchbomb: add a 'patchbomb.intro' option This option allows the user to control the default behavior for including an introduction message. This avoids having to tirelessly skip the intro for people contributing to Mercurial. The three possibles values are: - always, - auto (default, current behavior), - never. I was thinking of ("true", "false", "") (empty value being auto) but I ruled it out as too confusing. This new config option reuses the pre-existing 'patchbomb' section.

patchbomb: extract 'getoutgoing' closure into its own function This continues my crusade against closure complication.