Re: [boost] Getting Started with Modular Boost Library Maintenance

Subject: Re: [boost] Getting Started with Modular Boost Library Maintenance
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-17 02:47:55

>From https://svn.boost.org/trac/boost/wiki/StartModMaint:

> 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 --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.
>
> You might want to recommend a setting for branch.autosetuprebase or
provide a recommended .gitconfig in boostorg or on the web-site for all
boost developers.  I'd recommend branch.autosetuprebase=local (from the man
page):

branch.autosetuprebase
           When a new branch is created with git branch or git checkout that
           tracks another branch, this variable tells Git to set up pull to
           rebase instead of merge (see "branch.<name>.rebase"). When never,
           rebase is never automatically set to true. When local, rebase is
           set to true for tracked branches of other local branches. When
           remote, rebase is set to true for tracked branches of
           remote-tracking branches. When always, rebase will be set to true
           for all tracking branches. See "branch.autosetupmerge" for
details
           on how to set up a branch to track another branch. This option
           defaults to never.

> 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 rebase 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:
>
> git checkout feature/add-checksum-option
> git merge develop
>
> Otherwise the merge command above is wrong, since you always want to
rebase onto a feature/bugfix/hotfix branch from the branch it was branched
from.  It should be:

git checkout feature/add-checksum-option
git rebase develop

The new commits from develop will be replayed on the common ancestor and
the feature branch commits will be replayed on top of the new develop
commits, as if the new commits done on develop had been done before instead
of concurrently with the feature branch commits.

Michael