In D7620#112376, @dlax wrote:

This should be documented in mercurial/helptext/config.txt I think.

In D7617#112130, @mharbison72 wrote:

See D7065 and D7570. I didn't realize you could stack set: and the other patterns like this.

In D7506#111966, @dlax wrote:

In D7506#111947, @spectral wrote:

I don't think from . import show works generally.

I did that because test-check-module-imports.t complained otherwise when using from hgext import show:

hgext/phabricator.py:89: import should be relative: hgext

Also, there's already a similar from . import rebase in hgext/split.py so I thought that relative import was fine.
I'm happy to change if there's a solution, though.

I don't think from . import show works generally. I received errors because I imported phabricator via a path (pointing directly at the .py file, something like [extensions] phabricator = /home/spectral/src/hg/hgext/phabricator.py), not by doing something like extensions.phabricator=. I received the following errors:

In D7550#111235, @yuja wrote:

When the environment is empty (specifically: it doesn't contain LC_ALL,
LC_CTYPE, or LANG), Python will "coerce" the locale environment variables to be
a UTF-8 capable one. It sets LC_CTYPE in the environment, and this breaks chg,
since chg operates by:
- start hg, using whatever environment the user has when chg starts
- hg stores a hash of this "original" environment, but python has already set LC_CTYPE even though the user doesn't have it in their environment
- chg calls setenv over the commandserver. This clears the environment inside of hg and sets it to be exactly what the environment in chg is (without LC_CTYPE).
- chg calls validate to ensure that the environment hg is using (after the setenv call) is the one that the chg process has - if not, it is assumed the user changed their environment and we should use a different server. This will *never* be true in this situation because LC_CTYPE was removed.

Sigh. Can we work around this weird behavior by making chg do
putenv("PYTHONCOERCECLOCALE=0")? I think it's simple and more desired
behavior than the default of Python 3.

In D7544#110954, @mharbison72 wrote:

I don't think this is correct, because open is imported from pycompat at the top of the file, and that will sysstr() the mode. But this does seem confusing- see D7517.

Some slightly disappointing loss of clarity where we had originally had something like:

In D7024#103055, @pulkit wrote:

IIUC, you mean unambiguous instead of ambiguous in the commit message? Re-reading I am confused.

In D6989#102437, @indygreg wrote:

Question: should this checking be performed in exchange.push or at the command layer?
(I'm not sure of the answer.)

This shouldn't be about the user's chosen shell, though, right? This is about the /bin/sh implementation, which you wouldn't/can't replace with fish, so I think it won't bother users that use fish, just distros with really old implementations of /bin/sh.

I'm not sure what the current state of this is, but I don't want it lingering in the review queue while I'm not actively working on it.