On Windows, you can set a registry key to one or more *.ini files or directories that get read in, so it seems slightly handy to know the order in which files are processed. I know I've used that mechanism on various systems to find directories in which to stash things too.

In D7570#112206, @yuja wrote:

@yuja, what do you think?

I'm okay with this, but I would add "# TODO:" comment to subrepo handling
so future readers can see the problem. And one more nit: since cwd=b'' is
a valid path, we have to test cwd is None explicitly.

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

In D7517#111885, @durin42 wrote:

I'm a little fuzzy on this: should I see some test failures? or...?

In D7570#111783, @martinvonz wrote:

In D7570#111295, @yuja wrote:

if listsubrepos:
    for subpath in ctx.substate:

• sm = ctx.sub(subpath).matchfileset(pat, badfn=badfn)

+ sm = ctx.sub(subpath).matchfileset(
+ pat, badfn=badfn, cwd=cwd
+ )

Might have to adjust cwd since it may be relative to the parent's repo.root.

CC: @martinvonz

LGTM

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.

Windows is happy with this test

In D7464#109795, @dlax wrote:

Shouldn't this be also done for all similar functions? (i.e. _xmergeimm and functions registered as a merge tool with @internaltool)

In D7512#110589, @yuja wrote:

>>   """add a changegroup part to the requested bundle"""
>>
>> - if not kwargs.get('cg', True):
>>
>> +    if not kwargs.get('cg', True) or not b2caps:
>>
>>   return
>
> Is it valid to call these functions with `b2caps=None`? I suspect it would
> be a bug or a data corruption.
The only caller I can find[1] will indeed pass something, even if it is `{}`.  I can change these to asserts if you want.
[1] https://www.mercurial-scm.org/repo/hg/file/tip/mercurial/exchange.py#l2448

Well, I have no expertise around this module, so I have no idea which is
better. I just don't know if it's valid to return successfully if b2caps
is None.

In D7512#110528, @yuja wrote:

"""add a changegroup part to the requested bundle"""

• if not kwargs.get('cg', True):

+ if not kwargs.get('cg', True) or not b2caps:

return

Is it valid to call these functions with b2caps=None? I suspect it would
be a bug or a data corruption.

In D7516#110537, @dlax wrote:

Looks like dead code

In D7517#110547, @dlax wrote:

This is actually pycompat.open(), so it need bytes.

I don't understand why this is needed. The default value for "mode" as bytes comes from a407f9009392, but I don't understand the rationale.

Adjusting this to stay out of the review queue. While most of the files only had a handful of errors (and a few could be removed from the blacklist), the few added had a bunch of errors. I didn't see any obvious fixes, and ran out of time Friday to individually suppress them.

I only have a superficial understanding about how templates work, but I assume that there's no global pre-resolution step where a single query could be done and the results stuffed into the context or something, is there?

In D7506#110351, @dlax wrote:

The revisions shown by the "phabstatus" view is just a subset of that of "work" view (subset of revisions with a differential). Do you see more revisions in "phabstatus" than in "work" or am I misunderstanding something?

I'm not sure if there are plans to vendor *.pyi files. Maybe that could be used to backfill platform specific modules instead of doing this. But for now is seems better to get the error count and blacklist length reduced.

In D7506#110288, @mharbison72 wrote:

I'm not sure why, but this version seems to also show obsolete revisions. I've got a bunch of x and * nodes in hg-committed right now. I didn't see that before, although that was on a different clone that I don't have access to now.

I'm not sure why, but this version seems to also show obsolete revisions. I've got a bunch of x and * nodes in hg-committed right now. I didn't see that before, although that was on a different clone that I don't have access to now.

In D7295#107482, @indygreg wrote:

Since type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?

In D7506#110249, @dlax wrote:

In D7506#110225, @mharbison72 wrote:

I'm also interested in coloring the status value, but I can tinker with that after it's landed, unless you already have plans.

You mean having a different color depending on status value, or a fixed one? I have no plan anyways, so if you have good ideas, I'll leave this up to you.

I like it.

In D7258#109923, @indygreg wrote:

I seriously question whether we need a Makefile at all [on Windows]: our Makefile is just a glorified shell script and isn't doing much in terms of dependency management. I'm tempted to move the packaging targets to contrib/packaging and replace the remaining build targets with a build.py script.

To continue using Python 2, set the PYTHON variable. e.g.
make install PYTHON=python2.7 or
make install PYTHON=py.exe -2.