On Thu, Apr 11, 2013 at 6:45 AM, Dustin J. Mitchell <
notifications@github.com> wrote:

> In COMMITTERS.md:
>
> >
> > -When a new minor release branch is created (e.g. 3.1.x) then the previous one
> > -is deleted (e.g. 3.0.x). Any security or urgent fixes that might have to be
> > -applied to the older code line is done by creating an ad-hoc branch from the
> > -tag of the last patch release of the old minor line.
> > +First, merge the change set into the `stable` branch.  Next, rebase the change
> > +set onto the `master` branch and merge it in.  This merge strategy follows the
>
> Does this mean to rebase the merge commit itself, or rebase the set of
> changes being merged?
>
Ah, so this is a bit confusing.  I mean rebase the original set of changes
against the current HEAD of master.  The merge commit should be gone before
merging into master and the merge commit should be created when merging
into master.

The second rebase is helpful if the pull request is a bit old, it keeps the
history of changes relatively localized, rather than jumping back and forth
through time.

-Jeff