I'm not saying that your implementation of Git is bad. I didn't look at your code at all; it could be perfect, for all I know.
What I'm saying is you are not using git effectively. It is much easier to read and understand merge requests the smaller they are. Someone who didn't write the code should be able to go through your merge request in one sitting and understand all of its implications.
You may have written a good "implementation of Git," but you have also demonstrated that you don't know how to use it effectively.
> It is much easier to read and understand merge requests the smaller they are.
I'm always amused by people telling others what is more readable and understandable as if it was a hard fact and applied universally to all situations.
In reality, you can have a +19k diff which is easier to understand than a +100/-100 diff, and it happens quite often. Have you ever read a PR and clicked the "view" button to see the whole file? Have you ever clicked on the arrows to expand the context of a particular diff line to learn what the heck a given name is? Consider that you wouldn't have to do this if it was all in the diff in the first place.
The readability of the code is an elusive quality, with largely inconclusive research. There's very little in terms of facts to rely on. The best you can say is that a particular way of presenting the code, or changes, feels better to you. Good for you, but don't try to force that way on others, as you're guaranteed not to improve the readability and instead encounter a violent pushback.
Your personal preference for how a tool should be used is not the same as using the tool effectively. Pull requests aren't even an inherent part of the Git workflow, and not all projects prefer short-lived topic branches.
From the OP's other comment, it sounds like this merge strategy was the preference of the repository owner. Why substitute your own preferences for theirs?
ETA: Also note that the PR was reviewed several times over the summer. GitHub has a feature that allows you to only review changes to a PR since the last time you reviewed. You can also manually use `git diff` to review that difference.
What you are saying is bullshit, OP clearly explained the situation.
You just had no idea about the constraint he was facing, but even after he gave you a detailed answer you still not bother.
What I'm saying is you are not using git effectively. It is much easier to read and understand merge requests the smaller they are. Someone who didn't write the code should be able to go through your merge request in one sitting and understand all of its implications.
You may have written a good "implementation of Git," but you have also demonstrated that you don't know how to use it effectively.