config: rename allowpull to allow-pull As part of ConfigConsolidationPlan [1], rename the option according to the new UI guidelines [2] and add an alias for backward compatibility. [1]: https://www.mercurial-scm.org/wiki/ConfigConsolidationPlan [2]: https://www.mercurial-scm.org/wiki/UIGuideline#adding_new_options

convert: avoid wrong lfconvert defaults by moving configitems to core The `hg lfconvert --to-normal` command uses the convert extension internally to work its magic, but that produced devel-warn messages if the convert extension wasn't loaded by the user. The test in fcd2f9b06629 (modified here) wasn't showing the warnings because the convert extension was loaded via $HGRCPATH. Most of the config options default to None/False, but 'hg.usebranchnames' and 'hg.tagsbranch' are supposed to default to True and 'default' respectively. The first iteration of this was to ui.setconfig() inside lfconvert, to force the convert extension to load. But there really is no precedent for doing this, and check-config complained that 'extensions.convert' isn't documented. Yuya suggested this alternative. This partially backs out 0d5a1175d0f9.

tr-summary: keep a weakref to the unfiltered repository Repoview can have a different life cycle, causing issue in some corner cases. The particular instance that revealed this comes from localpeer. The localpeer hold a reference to the unfiltered repository, but calling 'local()' will create an on-demand 'visible' repoview. That repoview can be garbaged collected any time. Here is a simplified step by step reproduction:: 1) tr = peer.local().transaction('foo') 2) tr.close() After (1), the repoview object is garbage collected, so weakref used in (2) point to nothing. Thanks to Sean Farley for helping raising and debugging this issue.

dispatch: verify result of early command parsing Before, early options were stripped from args, and because of this, some kind of parsing errors weren't reported. For example, $ hg ci -m -Ra file would execute "hg ci -m file" in repository "a". This patch fixes the issue by parsing early options again by real getopt-based parser, and verifying the results. If the early parsing appears wrong, hg just aborts. The current error message seems not nice, and should be improved, maybe in V2 or follow-up. Note that this isn't a security feature because we can still do anything by using shell aliases.

dispatch: convert non-list option parsed by _earlygetopt() to string So we can easily compare it with the corresponding getopt() result. There's a minor behavior change. Before, "hg --cwd ''" failed with ENOENT. But with this patch, an empty cwd is silently ignored. "hg -R ''" has always worked as such, so -R has no BC.

dispatch: add option to not strip command args parsed by _earlygetopt() This allows us to parse the original args later by full-blown getopt() in order to verify the result of the faulty early parsing. Still we need the 'strip=True' behavior for shell aliases. Note that this series is RFC because it seems to change too much to be included in stable release.

dispatch: fix early parsing of short option with value like -R=foo Before, -R=foo was parsed as '-R' 'foo', which disagrees with the standard getopt behavior.

dispatch: abort if early boolean options can't be parsed Perhaps we'll need to restrict the parsing rules of --debugger and --profile, where this patch will help us know why the --debugger option doesn't work. I have another series to extend this feature to --config/--cwd/-R, but even with that, shell aliases can be used to get around the restriction.

dispatch: stop parsing of early boolean option at "--"

dispatch: extract stub function to peek boolean command option We should at least stop parsing at "--". The 'name' argument is passed for future extension.