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-27 16:01:44

On Thu, Dec 26, 2013 at 7:41 AM, Daniel James <daniel_at_[hidden]>wrote:

> On 26 December 2013 12:03, Cox, Michael <mhcox_at_[hidden]> wrote:
> > I'm not sure I follow the part about the nits.  As far as hot fixes go
> (or
> > any type of topic branch for that matter), the same process is followed:
> >
> >    1. The developer continually rebases other peoples changes onto the
> >    topic branch while working on the changes to implement the hotfix,
> feature,
> >    etc.
> >    2. The topic branch cleanly builds and passes all tests.
> >    3. Optionally the developer interactively rebases to structure the
> >    commits to a small number of logical commits, or if that's not
> important,
> >    --squash merges it into develop
>
> We have a lot of git novices here, getting them to continually rebase
> branches is probably a bad idea.
>

That's why I've suggested
here<http://article.gmane.org/gmane.comp.lib.boost.devel/247348> boost
should consider using bitbucket.org with its branch restrictions
features<http://blog.bitbucket.org/2013/09/16/take-control-with-branch-restrictions>
to
avoid accidentally rewriting history, if github won't provide that same
functionality (supposedly Github Enterprise has that functionality).

But I'm not suggesting moving to a rebase workflow policy vs. the git-flow
merge workflow policy. Even in a merge workflow policy, there are times
when rebasing is better.  See this interesting Atlassian blog
entry<http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/>
(the
creators of bitbucket.org) describing the unresolved debate about whether a
rebase or merge workflow policy is better and when rebasing is even
appropriate in a merge workflow policy.

Michael