Updating a Heavily-Customized Fork with New Release Features

Development Programming & Scripting C++
, , ,
1

So, I run a fairly heavily-customized fork of UE4 with changes throughout the Engine codebase (primarily in the renderer), and yesterday I hit the realization that I may be locked to 4.15.1 for the duration of my project, and that makes me sad.

Whenever I try to do a simple [FONT=Courier New]git merge, it ends up generating hundreds upon hundreds of files which all require diff’ing one at a time to make sure nothing slips through.

Is there some easier way of merging new releases or, at the very least, cherry-picking changes without losing my local modifications?

2

Not that things like this make it any easier:

From https://github.com/EpicGames/UnrealEngine
 * branch                  release    -> FETCH_HEAD
fatal: refusing to merge unrelated histories
3

I wouldn’t try such a thing from the command line. It works way better when you have a good tool like SmartGit to get all those diffs done quick.

4

I have my command line setup to invoke P4Merge for merges; that doesn’t really make the process easier given the volume of files in a major dot release. Even the 4.15.2 release is a non-trivial size.

I’m thinking I’m just going to have to cherry-pick as best I can from now on, but doing something like that with stuff like the compute shaders for post processing effects from 4.16 was… A bit painful.

I mean, one thing I could do is just take a release and overwrite a bunch of files and then diff the results of those to see where I lost code, but that seems like a pretty severe hack.

5

Normally, it’s ok for heavily modified forks to stop merging updates at some point as the cost of such merges becomes too high.

6

Yeah, I know there’s a cutoff point, I JUST WASN’T READY FOR THE BREAK-UP YET.

But I was also just wondering if there was just something I was fundamentally missing. I do think the idea of cherrypicking, overwriting all of my local files, and diffing against the current state of the remote repo will help the cherrypicking, though.

7

If you are really interested in some particular features from a newer version you can try manually backporting them to your current version. You can also try diffing two vanilla versions of the engine to see what changed. There’s no automated solution, I’m afraid.

8

Manual backporting can be such a hugely error-prone process; I actually think my ghetto “just take a commit, filter out the files that make sense, and just overwrite your working copy of them and diff the changes with the remote” may work.