At this point, I would appreciate a second pair of eyes to help diagnose why the test suite keeps failing on Python 3.7.

The one test that's currently failing was passing in my second commit (c0225b3), and my latest commit only re-wrote a small portion of the new test I added as part of the original PR.

Is this a flaky test that just needs a re-run? or is there something deeper that I'm somehow polluting in my latest revision?

Thanks for your contribution, it's appreciated.

I retried the CI a couple of times but it appears to consistently fail. Now tryingmain again to see if this is a new general issue, as I also wouldn't think this test should break after this change.

Andthe results are in:main is still working, which means something here has broken this one one test, consistently across python versions:test/test_base.py::TestBase::test_with_rw_remote_and_rw_repo.

As it still makes no sense to me, could you revert all your changes so this branch is the same content as main to see if this fixes it? I'd expect not, but I don't know what else to try. It appears anls-remote call has afile-not-found error, and generally it can't connect to the server running at localhost, which probably means it crashed or shut down.

Isaw earlier that you aren't a fan of force-pushes, but in this case, I found it much easier to squash my three commits into the one logical change that they are, then revert that single commit.

As expected, reverting this branch back to the code inmain ispassing on all counts, so there definitely seems to be some unexpected coupling between the testtest_with_rw_remote_and_rw_repo and my strictly additive change to theblame() function.

something here has broken this one test, consistently across python versions

Was there a CI run where Python 3.9 was broken? I'm only seeing failures forPython 3.7 andPython 3.8 and 3.10.

I'm not sure if that observation is helpful or not. Like you, I'm trying to scrounge up anything reproducible related to this failing test.

Well... reverting the revertappears to be passing. Do you see anything that explains that behavior?

Theoretically, if the reverted revert passes, then so should the standalone squashed commit. Would you like me to force push the branch with just the squashed commit, or just keep the double revert in the history?

Thanks so much for your help! Force pushing should do the job.
My guess is that it’s about the number of commits, as the test suite sees the GitPython repository, it’s not isolated unfortunately.

Thanks so much for your help! Force pushing should do the job.

Done, and it looks like tests passed again!

My guess is that it’s about the number of commits, as the test suite sees the GitPython repository, it’s not isolated unfortunately.

Well, at least it's an effective way to require PRs to stay small! XD

Thanks for your generosity with debugging this PR and open sourcing this powerful library!

🎉 Thanks for pulling through, this was much harder than it should have been 😅.