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.
Unfucking the repo, while mildly technically interesting should really be the smaller of the two lessons learned from such a mess... No?
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).
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!