In 25 years of UNIX era merging, the lion kingdom has never had a single patch file, CVS merge, SVN merge, perforce merge, git merge, or git rebase apply cleanly.  The modern dogma says to make a merge algorithm work, call it a new meaningless name, rewrite the same thing in a different programming language, insert a neural network somewhere to identify cars, or call it a company instead of a program & sell the company to salesforce.  

The typical day job involves making a lot of changes to make a product actually work but which the company rejected (the spacex patch), making the changes that the boss actually wants (the ULA patch), then applying just the ULA patch to the remote.  The trick is stripping out the spacex patch before submitting the ULA patch.  Taking up changes from the remote also involves its own merge crisis.  The git rebase advertised being able to do this automatically, but it has never really done anything but allow github to get bought out by Microsoft.

The lion kingdom has long pondered a way to aid the merging algorithm with code annotations.  It started with enclosing as much of the spacex patch as possible in ifdefs & manually tracking them down.  Something could probably be done with a config file that names whole files to swap & a tag to identify bits of a file to swap.  Ifdefs don't work with linker files, Makefiles, & IDE settings.  

The other problem is the desire to freshly check out the remote version & apply the spacex patch to it.  The locations to insert the tagged areas would still rely on traditional diff text searching.  Suspect at least having tags in the input patch would help immensely.  

The usual diff failure is caused by both files having different changes to the same line.  At least in a C program, we can keep both the patch file's line & the original line, tagging which one to use at compile time & which one to use at checkin time.  The automation is in removing all the functional bits so only the broken bits that the boss wants are checked in.