Re: Gtk+ merges

[Federico Mena Quintero <federico ximian com>]

On Mon, 2009-05-25 at 13:20 +0200, Alexander Larsson wrote:
> I see some commits in git master, like
> 4134c346f9e68367e515345c0ded07aa2b857a1a that looks kinda weird.
> Federico, did you really mean to merge all of the stable branch into the
> unstable branch, or did you just want to cherry-pick that particular
> commit? (To see how it looks weird, check it out with gitk on master)

I actually meant a merge; see below for the rationale.

> I don't think merging the stable branch ever makes sense, we don't want
> to merge e.g. a version bump in the stable branch to the unstable. I
> think the best approach is to commit fixes to master, then cherry-pick
> them to the stable branch.

The problem I see with cherry-picking is that you have to look in two
places to see if a fix appears in both branches.  If you merge from
stable to master, you only have to see if you re-merged after the fix in
question.

My rationale is:

1. At some point, the stable branch is created from master ("we go into
maintenance mode").

2. Only fixes go into stable.  Since they are stable, they should go
into master as well.

3. We can simply merge stable into master periodically, to ensure that
the fixes from stable are in sync.

See git/Documentation/howto/maintain-git.txt for a similar convention,
with some interesting elaborations.

About my particular merges (4134c346 and 26c10075), I should probably
have waited until both fixes were applied to the stable branch before
doing the merge, to avoid more graph-weaving than strictly necessary.
However, I don't think the current state is a problem.  The merges let
you see that the fixes are indeed in both branches, which is what you
want.

I did have to ignore diverging translations between the stable branch
and master, though.  For some reason they were, well, divergent, and
when merging stable into master, I simply retained master's translations
(my assumption is that the translators wanted to keep them different for
some reason).  However, I think even for translations they should
diverge as little as possible between branches, and merging instead of
cherry-picking can also help with that.

That "maintain-git.txt" also has a model for testing experimental fixes
that should go into the stable branch as well as master.  Essentially
all the action and experimentalt stuff goes into a "next" branch, the
new stuff known not to eat your hard drive goes into "master", and
finally there is the "maint" branch for stable/maintenance releases.

I think we are used to cherry-picking because there was just no other
sane way of doing things with SVN.  Cherry-picking is easy ("get me that
patch here"), but I think merging aids maintainability when you want to
ensure that branches have *all* the right fixes from other branches.

  Federico