On Sat, Dec 28, 2013 at 8:50 AM, Peter Dimov
Beman Dawes wrote:
Critical changes on develop dating from February were never merged to trunk, and I set the git merge point I missed them.
It turned out the changes were merged into branches/release at the time, and setting the merge point backed them out! It was probably operator error on my part. If I had followed the procedure you suggest below, I would have caught the problem, and done so at a time when it was (1) easy to fix, and (2) the command history was still available so I could have figured out what I did wrong.
To avoid such (and other) surprises, what I did was ensure that develop and master are identical before doing the first merge.
git diff --name-status master..develop
gave me an overview on where the two branches differ; the same command without --name-status goes into more detail.
(In principle, we all have kept our trunk and release branches in sync, so the above ought to have yielded nothing. In practice, however, all libraries likely had differences because (1) we sometimes forget to merge, (2) sometimes other people changed trunk and didn't merge and we didn't know, and (3) Stephen Kelly's Boost-wide changes were only on trunk.)
I then proceeded to identify the commits causing each change. I don't remember how exactly I did that, probably by using git log on the modified files and by looking at the commit history on Github.
After that, I applied each missing commit using git cherry-pick <sha>. That is, if a commit on develop was not present on master, I applied it to master with git cherry-pick; and if a commit on master was missing on develop (things like that do happen occasionally), I applied it on develop. I tried to do this in chronological order, which minimizes conflicts.
What made it more interesting for me is that I sometimes didn't want a commit to be part of the initial state, so I reverted it using git revert instead of applying it to the other branch using git cherry-pick; but this should probably not be needed most of the time.
The final result of all that cherry picking should be a state in which git diff master..develop doesn't report any differences. Once there, things are a simple "git merge" away.
It's probably too late now for all that explanation, but I already wrote it. :-)
I'll add your explanation. I may also move the merge point instructions to their own page to make them stand out more.
It may take a few days to figure out the best way to fix that.
The first thing I would try is git cherry-pick the missing commits into master.
I ended up reverting the entire merge point commit, and then compared master and develop to verify. (I used TortoiseGit to revert the commit because I wasn't sure how to revert a commit from the command line leaving subsequent commits in place.) --Beman