[Scummvm-devel] Towards a new release branch model

[Marcus Comstedt]

Tarek Soliman <tarek-spam at zeusmail.bounceme.net> writes:

> 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.

Exactly.  rebase is a little clunky because it doesn't support the
creation of a new branch in the same operation (rebase -b would be
sweet), but it's not so hard to work around it.  When done, you can
either use reset to make it the new head2, or merge --ff head2 to the
head of the throwaway branch.


> 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"

Well, in this case I understood the propsal as rebasing the commits
from the release branch onto the master, while still keeping the
original commits on the release branch (at least attached to a tag),
so it would be a "copy" even from an average end-users point of view.


> 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.

Agreed.  We should pick the workflow that minimizes work and risk of
mistakes, regardless of whether it is "the git way" or not.  It should
be _our_ way.  ;-)


  // Marcus