[Scummvm-devel] Release 1.3.0 schedule

Tarek Soliman tarek-spam at zeusmail.bounceme.net
Wed Apr 20 21:08:44 CEST 2011

On Wed, Apr 20, 2011 at 08:06:08PM +0200, Marcus Comstedt wrote:
> Johannes Schickel <lordhoto at gmail.com> writes:
> > Actually Tanoku (from github) told me that a cherry-pick might be
> > fine, though it is a very SVN style way of handling things. Seeing
> > that we want to start a release schedule tomorrow I don't think we
> > have enough time to decide on which proper workflow we want to use in
> > general.
> So which improper workflow do we want to use in particular then?  :-)
> Generally, there are three ways of handling a fix that should be on
> both the branch and the trunk:
> * Make the fix on the branch, and cherry pick to trunk (exactly like
>   what we used to do in svn)
The original proposal was a variation of this where the assumption
was that there were no commits on the branch that were not on trunk.
The proposal was to commit to the branch and then merge the branch
into trunk.

And yes I understand that with the current mindset we would have commits
on the branch that were not in trunk.
> * Make the fix on the trunk, and cherry pick to the branch
> * Make the fix on a new branch, based on a commit before the branch
>   was made, and merge this branch to both trunk and branch
What branch would that "fix" branch be forked off of?
> The last has the pro that the same commit object appears in both
> histories (which is good for "git branch --contains" and "git tag
> --contains"), but the con that it makes the history nonlinear, and
> therefore the logs somewhat more difficult to read.
I think between gitk (for GUI) and tig (for CLI) you can read little bumps.


More information about the Scummvm-devel mailing list