GIT - Rewriting core code on a separate branch

Question

I have this scenario which I do not think is uncommon but I am struggling to find an example of how it is done properly on the net.

We have our project, with a master branch. For my example lets say current state of the master identifies v1.5.0 of the project.

Now we decide to write v2.0.0, to which massive changes and rewrites will happen, files will be completely removed and deleted. This rewrite now takes place on a new branch we shall call unstable.

A week or so into development on unstable a feature and/or a bugfix needs to be added to v1.5.0, no problem we say new branch - write feature - merge with the master. The master is now at v1.6.0.

Now, this fix/feature does not apply to the new version of the project as the the entire project is being rewritten.

We complete v2.0.0 on the unstable branch which was originally based on v1.5.0 of the master branch which is now at say... v1.8.4 - how would you go about merging the unstable branch with the master branch without: destroying the history of versions 1.5 through to 1.8.4 or leaving artefacts from pre 2.0.0 versions in the merged branch and possibly breaking the new code written in v2.0.0?

Answer 1

You probably already know git merge -s ours, which does exactly the opposite of what you want to do: it ignores the changes in the source branch and lets the merge result be exactly identical to the contents of the target branch. There is no corresponding -s theirs, though, for reasons I'm not going to go into here.

So, we'll have to improvise something that has the same effect. Rough outline: do a merge without committing, magically mangle the 2.0.0 code into it, and then finalize the merge.

First off, make sure you have no uncommitted changes. We're going to be using fun tricks here; warranty void and all that.

1. on master, git merge -n unstable. The -n will make sure the merge isn't committed yet, even if there are no conflicts (of course you'll get conflicts due to your extensive rewriting, but let's be safe).
2. this is the magic: git read-tree --reset -u unstable (read unstable into the index and update the working tree accordingly, ignoring any conflicts)
3. git commit to finalize the merge. It will now have both old and new in its history, but only 2.0.0 stuff in the tree.
4. Check that this whole thing left no remnants of your previous master version as untracked files. I don't know for sure whether this can actually happen, but it can't hurt to check.