Changes between Version 1 and Version 2 of PostCvtMergePoint

Timestamp:

Dec 28, 2013, 4:05:04 PM (9 years ago)

Author:

Beman Dawes

Comment:

--

PostCvtMergePoint

@@ -7 +7 @@
 the {{{develop}}} and {{{master}}} branches so that Git knows the last point the two branches were in synch.  Once we've done that Git will perform a merge by replaying the commits on develop on top of master, starting from the last known merge: in other words Git will perform the tricky stuff of figuring out what to merge for us.
 
-You probably want to do this procedure before you start routine maintenance on your library. 
+You need to do this procedure before you start routine maintenance on your library as described in [wiki:StartModMaint Getting Started with Modular Boost Library Maintenance]. 
 
 == Preparation ==
+
+Peter Dimov suggested the following in response to problems Beman Dawes ran into with the merge point establishment:
+
+To avoid unpleasant surprises, what I did was ensure that {{{develop}}} and {{{master}}} are identical before doing the first merge.
+
+{{{
+cd modular-boost/libs/
+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 merge away, as described below.
 
 == Step-by-step ==