Changes between Version 16 and Version 17 of StartModMaint

Timestamp:

Dec 10, 2013, 2:14:18 PM (9 years ago)

Author:

Beman Dawes

Comment:

--

StartModMaint

@@ -93 +93 @@
 Since the bug is complex, it may take some time to fix and may go through several cycles of fixes, tests, and commits.
 
-To share work-in-progress with others, to create backup, or for any other reason you want to make the branch public, just push it:
-
-{{{
-git push --set-upstream origin bugfix/complex-boo-boo
-}}}
-
-Whether or not {{{--set-upstream origin bugfix/complex-boo-boo}}} is actually needed depends on the {{{branch.autosetupmerge}}} configuration variable that isn't discussed here. If you don't supply {{{--set-upstream origin bugfix/complex-boo-boo}}} and it turns out to be needed, you will get an error message explaining that.
-
-Eventually you will fix the bug and do a final commit, and then it is time to merge the {{{bugfix/complex-boo-boo}}} branch back into {{{develop}}}:
+Once the bug is fixed and a final commit is done, then it is time to merge the {{{bugfix/complex-boo-boo}}} branch back into {{{develop}}}:
 
 {{{
@@ -124 +116 @@
 }}}
 
- Public or private? When you create the branch, or perhaps later, you may decide the branch should be public (i.e. be present in the public boostorg repo) so that you can share it with others or just to back it up. Set that up by running:
+When you create the branch, or perhaps later, you may decide the branch should be public (i.e. be present in the library's public boostorg repo) so that you can share the branch with others or just to back it up. If so, set that up by running:
 
- {{{
-git push origin feature/add-checksum-option
+{{{
+git push --set-upstream origin feature/add-checksum-option
 }}}
+
+ Whether or not {{{--set-upstream origin bugfix/complex-boo-boo}}} is actually needed depends on the {{{branch.autosetupmerge}}} configuration variable that isn't discussed here. If you don't supply {{{--set-upstream origin bugfix/complex-boo-boo}}} on your first {{{push}}} and it turns out to be needed, you will get an error message explaining that.
+
 
 The usual cycle of coding, testing, commits, and pushes (if public) then begins. If other work needs to be done, a {{{stash}}} or {{{commit}}} may be done to save work-in-progress, and the working copy switched to another branch for awhile. If significant fixes or other enhancements have been made to {{{develop}}} over time, it may be useful to merge {{{develop}}} into the feature branch so that the eventual merge back to {{{develop}}} has less conflicts. Here is how the merge from {{{develop}}} to {{{feature/add-checksum-option}}} is done:
@@ -137 +132 @@
 }}} 
 
-== First post-conversion merge to {{{master}}} ==
+=== First post-conversion merge to {{{master}}} ===
 
-When you are ready to merge the {{{develop branch}}} to {{{master}} (or better yet a release branch that's branched off {{{master}}}), there's a bit of housekeeping to be done
+When you are ready to merge the {{{develop}}} branch to {{{master}}} (or better yet a release branch that's branched off {{{master}}}), there's a bit of housekeeping to be done
 the first time after the conversion from svn so that future merges proceed smoothly.  We're going to create a merge point between
 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
@@ -181 +176 @@
 Then navigate to your libraries history again, and check that the merge shows up, [https://github.com/boostorg/config/commits/master our config example is here].
 You're now ready for "routine" merges to proceed as per Gitflow (or whatever other strategy you wish to use).
+
+=== Library release ===
+