The tests run clean with this.

In D5801#87302, @martinvonz wrote:

In D5801#87300, @mharbison72 wrote:

In D5801#87296, @martinvonz wrote:

I noticed another bug and sent D5978. Maybe your test failure is because you're using the eol extension? I don't know what else would cause the \r in contrib.perf. I have no idea how that's related to this patch, though.

The \r is how output normally is on Windows. The test harness accounts for this when matching lines, but displays the actual output (with \r) when there are differences. The eol extension isn’t configured on this machine, but the custom HGRCPATH content from the test harness would override that anyway.

Ah, so the only difference is the extra "import newer module separately in try clause for early Mercurial" in contrib/perf.py then. This patch didn't change that file. Can you check again that it was this patch that caused that and that it's not just flaky?

In D5801#87296, @martinvonz wrote:

I noticed another bug and sent D5978. Maybe your test failure is because you're using the eol extension? I don't know what else would cause the \r in contrib.perf. I have no idea how that's related to this patch, though.

This seems to have converted a test from dos to unix style. I'm not sure if that was intentional, or if this feature is still a WIP. (Sorry, I've been busy lately, and haven't had time to follow this closely)

For some reason, this breaks test-contrib-perf.t:

Maybe a py3 thing?

In D5749#84825, @durin42 wrote:

In D5749#84719, @mharbison72 wrote:

In D5749#84640, @indygreg wrote:

@durin42 and I were both able to produce intermittent failures with this change. Why, I'm not sure.

Does the Windows regression occur with this patch or with D5751? I ask because the behavior of socket.shutdown() is documented to vary by platform. I wouldn't at all be surprised if D5751 caused the regression seen here.

It was this patch.

Like I said, I’ve seen connection resets in the non-daemonized serve output (don’t recall if it was push, pull, or both). I thought it was weird, but there were no other signs of problems, so I wrote it off as some odd Windows thing. (Not sure that I’ve seen it on Linux or OS X too)

Does D5764 help the situation? It made a big difference for me.

Since the tag command's code is already looking at repo.tagtype(), I wonder if it would be better to just inline the global tag lookup and nullid comparison right there instead of updating the interface.

In D5749#84640, @indygreg wrote:

@durin42 and I were both able to produce intermittent failures with this change. Why, I'm not sure.

Does the Windows regression occur with this patch or with D5751? I ask because the behavior of socket.shutdown() is documented to vary by platform. I wouldn't at all be surprised if D5751 caused the regression seen here.

While this is better, it triggers a few failures on Windows. I've seen these connection resets with hg serve outside of the test harness. Any ideas? It almost seems like the client is closing the socket before all of the data is sent. (This failure occurs on py2)

In D5496#82908, @angel.ezquerra wrote:

In D5496#82671, @yuja wrote:

Do you mean that the flag should only indicate whether you want to hide the same branch merges? I guess that is OK too, since the main use case for this flag is to hide the merge from the same branch. However I think we should change the flag name then. Perhaps "hidesame"? Or "includesame" or "includeself", defaulting to True? Any ideas?

In D5495#82416, @angel.ezquerra wrote:

I've sent an updated set of patches, following your recommendations. There are 2 patches now, since each includes its own tests. This means that the 3rd patch on the original patch set is no longer needed. However I don't know what is the best way to tell that to phabricator...

This works for me on Windows in that narrow window where this was constantly happening, thanks!