From kde-core-devel  Fri Jul 22 23:00:16 2011
From: Nicolas Alvarez <nicolas.alvarez () gmail ! com>
Date: Fri, 22 Jul 2011 23:00:16 +0000
To: kde-core-devel
Subject: Re: Fixes in Git (first in stable, then merge to master)
Message-Id: <j0cve2$vs4$1 () dough ! gmane ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=131137568902630

Alex Fiestas wrote:
> Last few days I have been patching some pieces of our workspace here and
> there, the first set of patches I did them directly into master which if
> I remember correctly was against the policy.
> So, the second round of fixes I tried to do it the right way, which is:
> 1-Create the patch while using 4.7 (optional I guess)
> 2-Test the patch in 4.7
> 3-Commit the patch in 4.7
> 4-Checkout master branch
> 5-Merge 4.7 into master
> 
> [...]
> 
> So, at this point I'm wondering if the policy is bad or (and this option
> is the more plausible) I don't know how to use the tool.
> 
> Cheers and sorry for the cherry-pick's I've done so far.

There is no active policy saying you're supposed to merge. Almost everybody 
in KDE is still doing cherry-picks. KDevelop is the only KDE project I know 
that consistently uses forward-merges from the stable branch to master.

---

It *would* be good to switch to the new workflow of doing changes in the 
lowest supported branch and up-merging, but it's not that easy. We need to:

- Figure out how to solve the scripty problem. scripty does its own 
conflicting commits to .desktop files in both branches, and that won't 
change[1]. We probably need a custom merge tool for .desktop-like files that 
ignores translations.

- Check if there is any change in 4.7 that isn't in master, and if so, see 
if that's intentional (4.7-specific hack, or the version bumps) or an 
oversight (never cherry-picked into master).

- Do the initial merge from 4.7 to master, solving the conflicts. The more 
they have diverged, the harder this is.

- Get *everyone* to start with the new workflow for that particular 
repository (see below). Else, if some people keep cherry-picking while 
others expect merging, the next one to try merging may get conflicts about 
all the cherry-picks people did since the last merge, and a merge will make 
commits appear duplicated in the log (as ossi pointed out to me).

Off to read about custom git merge drivers...

-- 
Nicolas