Hmm, I wasn't trying to come off that way, although I wasn't trying to be helpful with the specifics of their git nightmare since happily they sorted it out anyway: I was only trying to suggest that the only way you "clean up" from a nightmare such as that is to start looking at what seems to be an obviously fragile way of dealing with their code since that's the real problem..
Unfucking the repo, while mildly technically interesting should really be the smaller of the two lessons learned from such a mess... No?
It's a little tone deaf to offer "should've done it this way!" as advice to a person already in a bad way.
Unless OP is asking for better processes to avoid this in the future, I think it's not a good idea to offer preventative advice as a first response. YMMV, but this sort of comment is often unwelcome (especially if you phrase the questions in an interrogative way... example - "Why are you landing 400 commits in one go? Half of those were on files which then start causing merge conflicts for your team and wasted a huge amount of your time?" comes across like you kind of enjoyed typing it and doesn't really occur as a kind stranger leaning in to help)
If your post was directed more to the readers of the thread instead of at OP, I think it would've come across less admonishing. Of course, I'm not judging you for your comment to be clear, just providing feedback on why your comment might rub people the wrong way (apologies for length).
Hm, well -- OP; I wasn't trying to have a go if you thought that, and the question wasn't rhetorical -- if you're up for sharing how this sort of thing comes to pass I'd love to have your story/discussion..
As for coming across like I enjoyed typing it, I'm pretty much at a loss on how to respond to that one besides: NEIN!
No, the cause of the problem was a process one, but now it's become a technical problem.
That isn't really helpful when someone has already created a git nightmare like what's described here.