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

On Thu, Dec 26, 2013 at 7:41 AM, Daniel James wrote:

On 26 December 2013 12:03, Cox, Michael 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 herehttp://article.gmane.org/gmane.comp.lib.boost.devel/247348 boost should consider using bitbucket.org with its branch restrictions featureshttp://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 entryhttp://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