In D6851#100690, @idlsoft wrote:

Just tracked --add-include. A workaround to simplify the upgrade would be to change wireprototypes.SUPPORTED_ELLIPSESCAP to be (ELLIPSESCAP1, ) on the server from now until all clients have upgraded. But that may still be annoying and error-prone for you to deal with. @pulkit, I suppose we should just add a exp-narrow-2 capability to deal with this? It doesn't seem fair to make @idlsoft deal with it.

Sounds like a good idea!

If it's just tracked --add-include then it's not a big deal, it won't disrupt regular flow.
If backward compatibility doesn't complicate the code - great, if not - don't worry about it.

In D6851#100666, @idlsoft wrote:

@idlsoft and their company does use narrow extension. @idlsoft can you upgrade server and client at the same time?

I did that a little while ago to move to 5.0. It was not fun. It's server, teamcity, clients, docker images.
What operations does this affect? Regular push/pull/clone or only tracked --add-include?

Hmm, I just noticed that we separate these paths by commas (not nulls) in other places, so I'll make this consistent with that. I guess that means we don't support paths containing commas for includes or excludes, but fixing that is a separate problem.

In D6789#100218, @martinvonz wrote:

The only information about it that I could find is that Bourne Shell doesn't support $() syntax. I'll still send a patch to mention it in the release notes.

The only information about it that I could find is that Bourne Shell doesn't support $() syntax. I'll still send a patch to mention it in the release notes.

In D6782#99619, @yuja wrote:

@@ -245,8 +245,11 @@

    pycompat.fsencode(getattr(mainmod, '__file__', ''))) == 'hg'):
    _sethgexecutable(pycompat.fsencode(mainmod.__file__))
else:

• exe = findexe('hg') or os.path.basename(sys.argv[0])
• _sethgexecutable(pycompat.fsencode(exe))

+ exe = findexe('hg')
+ if exe:
+ _sethgexecutable(pycompat.fsencode(exe))
+ else:
+ _sethgexecutable(os.path.basename(pycompat.sysargv[0]))

findexe() is supposed to return bytes. If not always, it's the bug
of findexe().

test-check-*.t were unhappy with some of the changes in this stack (including in this patch). Can you fix those and update?

I've been trying to understand where time goes in hg status and this helped
me get a sense of things.

In D6775#99509, @yuja wrote:

• a/mercurial/utils/procutil.py

+++ b/mercurial/utils/procutil.py
@@ -246,7 +246,7 @@

    _sethgexecutable(pycompat.fsencode(mainmod.__file__))
else:
    exe = findexe('hg') or os.path.basename(sys.argv[0])

• _sethgexecutable(exe)

+ _sethgexecutable(pycompat.fsencode(exe))

Perhaps, pycompat.sysargv has to be used instead. Applying fsencode()
on sys.argv might be incorrect on Windows.