[Scummvm-devel] Towards a new release branch model

[Marcus Comstedt]

Miguel Bernabeu <mukik182 at gmail.com> writes:

> I'm sorry but I didn't understand completely. In my opinion cherry-picking
> isn't the same as rebasing.

They are in fact exactly the same thing, only the UI differs.  With
cherry-pick, you specify which commits you want, one by one.  With
interactive rebase you get a list of commits and you get to remove
the ones you _don't_ want.  In both cases you add new commits which
are copies of the ones you rebase/cherry-pick.


[...]
>
>       /-D-F     2
> -A-B-C-E-G  1  Initial situation
>
>
>      /-D-F-----\
> -A-B-C-E-G-H  1   After merge.

You don't need to make this merge, you're going to throw it away
anyway.  Just rebase branch 2 --onto branch 1.

>
>                1
>                |
> -A-B-C-E-G-D-F   After rebase 1.

Or after cherry-pick of D and F onto original 1.  Same thing.


>
>       /-D-F         2
> -A-B-C-E-G-F   1  After cherry-picking F.

Or after rebasing 2 --onto 1, and dropping D.  Same thing.


So I hope you'll see now how rebase and cherry-pick is the same thing;
there are different ways you can use rebase and cherry-pick, but they
are in fact interchangeable with each other:  You can use cherry-pick
to do the same thing as rebase, and vice versa.

But as I said, while the end result is the same, the UI is different.
That's not an entirely unimportant point.  If you rebase the release
branch onto master at the end of the release cycle, then you don't
risk missing any commit which should be added, because the default
will be to include all commits after the branchpoint.  Instead, you
need to remember which commits should _not_ go to trunk, so that you
can change "pick" to "drop" for those.  Here it would be possible to
use some kind of syntactical marker in the commit message to make it
easier though.


  // Marcus