Thanks a lot for the fix, the thorough PR description and for trying to even put this into a test.

No matter what, this fix should definitely be merged as I have a feeling it did break a lot of things downstream and it's surprising there weren't any bug reports yet.

... and it's surprising there weren't any bug reports yet.

I think I've got some idea why there weren't any yet. My team's been encountering this problem for at least as early as about June 2019 (unfortunately our CI logs don't go further than that). But it was very rare, and we couldn't consistently reproduce it.

Then somewhere early in 2020 the frequency of this happening jumped up to close to 100% but our initial attempts to diagnose it where unsuccessfuland we had a simple workaround (disabling the use of multiple nodes in our Jenkins setup to prevent the need to fetch into worktrees from one node to another). My colleague who did that investigation felt, at the time, uncomfortable filing a bug report without having a good reproduction scenario. I later discovered that the cause of this frequency jump was a commit to our meta-CI systemtomtom-international/hopic@14a4338 (that change causes the introduction of a conditional, but almost always occurring, extrarepo.remotes.origin.fetch([list-of-commit-hashes]) on newly allocated build slaves,just before fetching into any configured worktrees).

It's the combination of fetching first in the top-level and only then fetching in a worktree thatmay cause this bug to cause an exception to be raised. In plenty of other cases you may just silently get wrong results being returned fromremote.fetch(...). That makes it difficult to detect at all let alone consistently reproduce.

Then the error we got itself (and the above reproduction script will give with the old version) is also misleading: it's aTypeError suggesting that GitPython is somehow unable to parse a stderr orFETCH_HEAD line. So the direction of investigation my colleague took was trying to figure out what line that was and how to get it to that piece of code.

I still believe there's at least one bug, maybe two, in the processing ofstderr &FETCH_HEAD there. But this was the one I managed to disentangle yesterday after pure curiosity + frustration motivated me sufficiently to do a deep dive for close to two full days on this one. I'll create two bug reports for those right away, even if the information I can provide at this time is very partial at this time.

I hope that bit of history helps to understand at least partially why this hasn't been reported before. The (feeling of) inability to describe what the problem is is a big obstacle there.

Anyway, thanks for your quick response :-)

Thanks so much for sharing, but… oh my…every paragraph I could feel the time spent and nerves lost and it hurt :/.
Having maintained GitPython forever now I do know for sure that it is not at all 'good' software, and many more bugs an issues are lurking to cause nasty surprises to people who definitely shouldn't have to deal with them.

Even though for GitPython I do believe the fight is lost,there is another endeavour which will definitely reach an entirely new level of quality. Maybe one day it willeven arrive in Python.