After reading the thread "avoiding fast-forward merges" and looking at the latest https://svn.boost.org/trac/boost/wiki/StartModMaint, I'm getting totally confused on the boost git flow. I thought all the commits on the develop branch of all the repositories are fast forwarded onto their master branches. Note, that the --no-ff still tries to fast forward the branch and adds a merge commit if the fast forward succeeded to "mark" the merge into master (not sure this is really necessary, since you should have a tag on that last fast forwarded commit The develop branch should *always* fast-forward, unless some history editing has occurred. Here's the description of the fast forward options from the man page of git-merge. --ff When the merge resolves as a fast-forward, only update the branch pointer, without creating a merge commit. This is the default behavior. --no-ff Create a merge commit even when the merge resolves as a fast-forward. This is the default behaviour when merging an annotated (and possibly signed) tag. --ff-only Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward. In fact, since we can't enforce fast forward merges on the server side on Github, The command line option should be --ff-only. That way if the merge fails, you know somehow a commit got on master that isn't on develop or maybe you have some stale branches you need to re-pull. With the --no-ff option and a master that isn't in sync with develop, you'll just put a merge commit on master and not fast forward the development history from the develop branch onto master. If you're lucky, you might get some merge conflicts that will alert you to the problem. On the StartModMaint page, there is command line sequence: cd modular-boost git checkout master git pull git submodule update Shouldn't that be "git checkout develop"? Are we not using the develop branch at all? Michael P.S. I tried to merge the develop branch onto the master branch in my superproject of my local repositories to simulate a release of boost. I got a ton of conflicts (looks like mostly submodule reference commits). Michael On Tue, Dec 10, 2013 at 9:41 AM, Beman Dawes <bdawes@acm.org> wrote:
I've been pecking away at "Getting Started with Modular Boost Library Maintenance".
See https://svn.boost.org/trac/boost/wiki/StartModMaint
I'd appreciate comments and corrections.
One of the questions that came up was how to number releases for individual libraries.
Say Boost.System wants to do a release before the next full Boost release ships. What do I call it? How do I document it? How do I tag it?
Strawman proposal ------------------------
* Call it "Boost.System 1.55.1 Point Release".
* Document it via the "readme" file that GitHub pesters you to add. Contents would give the title of the release and the release notes.
* Create a gh-pages branch with the same release notice.
* Tag it 1.55.1
Comments?
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost