(marking as request changes in that case)

I suspect this test works without network if setuptools is already installed, but I don't care enough to block it on that pedantry.

AFAICT this should be fine, but I'll give Yuya a while to catch problems.

I'm still confused here.

This still requires changes to resolve my comments.

I'm not happy about this footgun option, but see why we need it.

I'm honestly baffled, and don't really have time to take a look. Probably back this and its child out, and we'll roll it forward again after we drop py2?

Do you think we should go ahead and apply the local patch then until we can update the vendored copy?

Should we add a test that, if git-fast-import is available, actually tries the import and verifies that things look reasonable?

Yes, please remove the python-zstandard changes from here, and send them directly to @indygreg upstream for that.

I'm fine with this as-is, but I am sympathetic to the concern that the -- looks like a mistake. If we want to change it we can, since we've got a full release cycle ahead of us before this is binding.

Ping someone else please - I'm busy with other things this week. :(

That’s super surprising to me, because it hasn’t passed for me _for months_ and our work systems should be basically identical.

So, I'm still not sold on the "only one hash function in a repo, ever" constraint of the design this seems to imply. Is there a plan page or anything or is this all in your head?

needs rebased

I guess I don't really understand the position of "we should back this out" particularly. Given that it's a test-only change, could we just roll-forward with the new test discussed (that is, a variant of this test with the content the same for all the files)?

This is wrong. Subversion does not, by default, allow you to propset things like the date unless you're the repo administrator, and even if it does, you shouldn't do that. LOTS of things in Subversion have hard dependencies on the commit timestamps monotonically increasing, so this isn't something we should ever attempt.

I'm fine with this as long as it still works on Python 3. Can you confirm this works under Python 3? Maybe rebase it to @ for completeness, since it's been a while.

I'm fine with having them I suppose.