On 12/28/2013 08:46 AM, Beman Dawes wrote:
On Sat, Dec 28, 2013 at 8:50 AM, Peter Dimov
wrote: 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! [...]
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.
I'll add your explanation. I may also move the merge point instructions to their own page to make them stand out more.
Setting the merge point is the most critical, and most fragile, step. From playing with this in Boost.Test there are too many failure modes to anticipate, so careful review of the content at each step is very important. I have an annotated script showing the steps I performed in that case, which might be educational; I'll post it separately after I review it.
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.)
I highly recommend "git rebase -i" (interactive rebase) to do this sort of thing. Interactive rebase allows you to reorder (and remove) individual commits, squash together commits, and generally clean up the history of a branch so it's clean before you make it public. Peter