[Scummvm-devel] Towards a new release branch model

Tarek Soliman tarek-spam at zeusmail.bounceme.net
Wed Jun 1 16:41:28 CEST 2011


On Wed, Jun 01, 2011 at 02:43:40PM +0200, Marcus Comstedt wrote:
> 
> 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.

The most important difference is that a rebase will remove the current head and re-place it on top of the other head.
This means the copies are the only ones that are relevant, the originals are more or less dead.
With cherry-pick both heads remain where they are (separate).

Of course you can make a throwaway head at head1, rebase that, and then reset head2 to the throwaway head.
That will be the equivalent of cherry-picking all differences. If you do it interactively, then you blow away any commits you don't want.

Both what I just said and what you said should be pretty confusing to anyone not very familiar with git.

My point is that from the average end-user point of view rebase doesn't make "copies" even though we know it does.
When someone says "let's rebase" they don't mean "let's do a 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.

This is where git really becomes "the new crappy tool".
In our quest to "do things the git way" we end up making ridiculous rules like "the commit message has to be clear on the first line if it should be picked as part of an interactive rebase"
This shouldn't be the case. We shouldn't come up with workflows that make life harder.

-- 
Tarek




More information about the Scummvm-devel mailing list