Next to master, I have another remote repository remote/master from where I want to pull the changes then and again. This happens only about after every 20 commits or so. Consequently, it always generates these big behemoths of merge conflicts, where git wants me to resolve all 20 possible conflicts from 20 commits at once, without any further guidance.
Is there a way to be able to merge the branch, going through the commits one by one? So I can cross-check the individual conflicts with the commit messages and act accordingly. I understand that this could introduce unnecessary work when a commit undoes the changes from a previous one, but that is a very acceptable trade-off.
I know I can git cherry-pick them all, but how would I know since when to cherry-pick? Manually checking the log before every fake-"merge" process? Also, I'm not actually cherry-picking here. I want to combine two branches into one, but not all at once, as in
git pull --one-by-one remote master
Is there a way to be able to merge the branch, going through the commits one by one?
Not really, that's not how git does its thing. I guess you could merge each intermediate commit one by one, then take the resulting tree and create a synthetic "merge" commit.
I know I can git cherry-pick them all, but how would I know since when to cherry-pick?
There's git merge-base, but I don't think that makes any sense. remote/master would usually be the "blessed" upstream, by cherrypicking its contents you're going to create completely unrelated commits in your branch (with similar content but not actually matching).
Most people would instead rebase their local changes onto the upstream.
This happens only about after every 20 commits or so. Consequently, it always generates these big behemoths of merge conflicts
That sounds like some seriously weird development methodology.