In D7627#112223, @martinvonz wrote:

In D7627#112220, @mharbison72 wrote:

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.
That said, I don't think I feel strongly about keeping it if it makes the next patch messy. (I did a quick skim of it, but didn't see why that would be.)

It means that every line in merge-tools.rc would get two lines in this output (one line saying "set value from ..." or something like that).

In D7630#112243, @rdamazio wrote:

(on mobile) I think it was hg phabsend -r .+.^

In D7627#112220, @mharbison72 wrote:

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.
That said, I don't think I feel strongly about keeping it if it makes the next patch messy. (I did a quick skim of it, but didn't see why that would be.)

In D7603#112088, @gracinet wrote:

Here's a quickfix that works for me for both pure and C

-- a/tests/test-parseindex2.py Thu Dec 05 20:41:23 2019 +0100
+++ b/tests/test-parseindex2.py Thu Dec 12 18:34:28 2019 +0100
@@ -18,6 +18,7 @@
     node as nodemod,
     policy,
     pycompat,
+    util,
 )
 parsers = policy.importmod('parsers')
@@ -267,11 +268,12 @@
         appendrev(6)
         self.assertEqual(len(index), 7)
-        del index[1:7]
+        del index[1:-1]
         # assertions that failed before correction
         self.assertEqual(len(index), 1)  # was 4
-        self.assertEqual(index.headrevs(), [0])  # gave ValueError
+        if util.safehasattr(index, 'headrevs'):  # not implemented in pure
+            self.assertEqual(index.headrevs(), [0])  # gave ValueError

Explanation: the C version would allow either -1 or actual length, the pure version just allows -1. The pure version does not have algorithms such as headrevs, they are implemented in revlog.py
I can redo that cleanly, just tell me the expected way.

In D7595#111986, @pulkit wrote:

Applying this on top of D7605 failed. So unfortunately you have to rebase again and resend. Also, I think you are pip install black away from preventing such conflicts.

This broke ./run-tests.py --pure test-parseindex2.py

In D7118#111784, @Alphare wrote:

In D7118#111735, @martinvonz wrote:

What's the state of this patch? The description makes it sound like it's a Rust patch, but it only modifies Python code.

It only impacts the rust module policy, I figured the name was not a bad idea. Maybe I'm wrong?
I also did not find Yuya's suggestion to work, but I may have understood it wrong.

In D7570#111903, @martinvonz wrote:

In D7570#111892, @durin42 wrote:

I'm happy with this, but didn't spend time figuring out if all concerns have been addressed (I'm mostly doing a fast triage path).

I *think* they're addressed, but we there's no rush to get this in so let's give Yuya a chance to comment, because I'm not sure if the issue with subrepos is an existing or new issue.

In D7492#111988, @marmoute wrote:

In D7492#111595, @martinvonz wrote:

Hmm, I thought this entire series had been queued. I'd like to queue it. Can you include perf numbers?

Now that we have a reference filtered repository, I am planning to use the benchmark suite to gather timing (probably next week). We already track status and diff. addign hg export is easy. However I am not sure what's your criteria for annotate ? Can you clarify them and offer a file to test for each for the reference repositories ?

In D7522#111970, @Alphare wrote:

@martinvonz I was scratching my head trying to find this changeset to update/rebase it, here's hg obslog -r 5a1ff3d75f35 --hidden:

x  5a1ff3d75f35 (46379) rust-dirs: handle forgotten `Result`s
|    rewritten as 80c3e3d4ddea by Martin von Zweigbergk <martinvonz@google.com> (Wed Dec 11 10:51:38 2019 -0800)
|
x  2c62ed1a015a (46378) rust-dirs: handle forgotten `Result`s
     rewritten(description) as 5a1ff3d75f35 using phabsend by Raphaël Gomès <rgomes@octobus.net> (Wed Nov 27 14:30:10 2019 +0100)

I don't have 80c3e3d4ddea in my local repository. I could just revive 2c62ed1a015a and edit from here, but I'm worried that might complicate things further.

In D7570#111892, @durin42 wrote:

I'm happy with this, but didn't spend time figuring out if all concerns have been addressed (I'm mostly doing a fast triage path).

This no longer applies cleanly (and doesn't build when applied with fuzz)

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.

Did you mean s/explicitmatcher/exactmatcher/ in the description? Also, I thought you called it FileMatcher instead. What's the difference?

What's the state of this patch? The description makes it sound like it's a Rust patch, but it only modifies Python code.

In D7593#111728, @rdamazio wrote:

In D7593#111696, @pulkit wrote:

I pushed @martinvonz D7591, so these need to be rebased. Thanks!

Are you asking me to do something, or are you going to?
This supersedes his change completely.

Abandoning in favor of D7492

I'll abandon this in favor of D7492

Hmm, I thought this entire series had been queued. I'd like to queue it. Can you include perf numbers?

In D7591#111571, @rdamazio wrote:

In D7591#111570, @martinvonz wrote:

In D7591#111569, @rdamazio wrote:

FYI I'm going to send a chain that rewrites a lot of this

To be clear, are you telling reviewers not to queue this one because you will be rewriting the *patch* or you're saying that you will later be sending patches on top of this one?

I'm writing a larger change which includes this change, I don't mind merging the conflict if you want to go ahead and queue this.

In D7591#111569, @rdamazio wrote:

FYI I'm going to send a chain that rewrites a lot of this

In D7500#110252, @marmoute wrote:

Yes we could.

Could we just add all these tests from the beginning? It seems they would look almost the same if added early in the series, just with some extra "getting filtered repo" lines (or whatever they say). If the tests were added earlier, it would be clearer which changes affected which tests.