Sometime ago I had the nice idea of suggesting my boss we should rewrite the build system, to automate many tasks we were doing by hand or scripting, our old build system was based on SCons so I took this awesome tool as base, thing is I ended up writting a few tools, and now we are in the stage of merging things.

Problem is that many of our project where a mess when it comes to include paths and defines, we had things like include paths that referenced files inside directories from projects, instead of the root of the project, exposing internals, then we had many aweful things like:

#define HEADER_IMPL <somefile.h>
....
#include HEADER_IMPL

So I did many modifications to the projects to make it look nicer, and easier for new people to jump into development without having to guess what the heck was going on under the hood, now we have something as:

Problem is I ended up with about 200 commits in git, and the branch I was working on was all ready a topic branch, so then the pain started over, merging those changes back into the master branch, now here’s the problem….. we can’t just merget! Because that would break some of the company products, so I needed a way to control what got merged and what not.

I investigated a little and come up with a not as elegegant as I want solution, but good enough anyway:

git format-patch FIRST_COMMIT..LAST_COMMIT
git am --reject *.patch

The first command will extract all the patches and format them for mailing, the second one wills start applying one after the other, and if by some reason a patch fails to apply it will generate .rej files and let the user interact before going on. Once the issue is solved you need to do:

git am --resolved

Off course this isn’t as nice as merging, but unfortunately I have no other way to handle this, as we need the new build system in the old branch, while still can’t merge the changes the made master and my reference branch diverge.