Git merge: one legitimate use and a goof
Git merge: one legitimate use and a goof
In spite of the general allergy that Git users have against merge, there are perfectly legitimate uses for it. I currently work in a project where merging is routinely used.
The story is: my work is based on someone else's project, let's call it project Foo. I keep a branch called fixes, which is based on Foo main line of development, plus some bugfixing commits that have not been integrated back into Foo yet.
Since Foo is in active development, I need to rebase fixes often, so the patches will apply cleanly when Foo maintainers take a look on them. Some fixes are independently made by Foo, so my patches conflict and sometimes become obsolete, and they can simply skipped.
Then I have the feature branch, that is, as expected, an implementation of a new feature. I need to base feature on fixes branch, so when I rebase fixes against Foo's mainline, in turn I rebase "feature" again, too.
I have a third branch, called testing, which adds some code to fixes branch. Those never make it into the main project, but they are needed for testing, because the code I work on is still unreachable from other parts of the application. It is based on fixes branch too, and it is rebased often as well.
Now, the problem: I need to test my new feature. It is not possible to rebase on both feature and testing.
But, since they touch completely different sections of code, merging becomes trivial. So I created the feature_testing branch, which is based on testing, and then feature is merged.
It is a legitimate use of git-merge (or sounds legitimate to me) because
When either testing or feature changes, because of my development or because they had to be rebased against Foo, in general I try to update feature_testing using rebase and merge again. It works in 3 out of 4 times. But sometimes it fails, so I simply rebuild it from scratch, as if I did the first time.
Now, the goof :)
I develop this thing in 3 computers and need to push/pull commits often. Generally I take care to avoid merges in history, so all push/pulls are fast-forwarded. But I did let one merge slip into the history. I thought it could not do much harm, because, after all, it was merging two almost identical branches.
Bad mistake, because I have to rebase testing often on fixes, as I said. Git got completely lost in the next rebase because of this merge.
Could Git be more "intelligent"? Perhaps, but the fact was that rebase was full of conflicts and this testing branch have commits that I can't lose.
Well, time to resort to the "stupid" technique: dump the patches and apply manually. I did a
git format-patch -n HEAD~15
and about 100 patches were dumped. What the %&#$ ?!
Then the cause of problems was immediately obvious: the "same" patches were dumped twice, one from each merged branch, and of course that failed in rebase because it was trying to apply the same sequence twice.
Since I had the patches "saved" now, I resorted to recreate the testing branch from fixes and apply the additional patches using git am. Once the duplicates were eliminated, a git am 00* without -3 worked perfectly.