So there are a bunch more bugs in the tree.py code, but as I was writing a set of tests for it I discovered that it's even buggy in py2 in places -_-. It looks like most of the code isn't really used (I suspect the mercurial version of the code is what is mostly used, and GitTree was just coded to theory). So ultimately I just ended up doing these specific fixes.

Looking at https://github.com/web-platform-tests/wpt/blob/master/tools/wptrunner/wptrunner/update/tree.py , I see mostly (if not all) native strings when interacting with git output. Shall we perhaps always decode in vcs?

I think the hg code for tree.py was almost never used, but the git code maybe was for gecko (historically) and Servo (possibly still). It's definitely not very well maintained though.

Looking at https://github.com/web-platform-tests/wpt/blob/master/tools/wptrunner/wptrunner/update/tree.py , I see mostly (if not all) native strings when interacting with git output. Shall we perhaps always decode in vcs?

I thought about this, but wasn't sure. It is reasonable to expect both git and hgto always return utf-8 encoded data? In any case there are a lot of callers in wptrunner and I'm wary of changing this without mypy support (which is a big undertaking).

I'm going to go ahead and merge this, since it tripped me up when recently trying to run MacOS + Py3 again.

I thought about this, but wasn't sure. It is reasonable to expect both git and hg to always return utf-8 encoded data?

Not sure about hg, but git is almost encoding-agnostic, so assuming UTF-8 isn't technically correct, sigh...

In any case there are a lot of callers in wptrunner and I'm wary of changing this without mypy support (which is a big undertaking).

LGTM