Merge or Cherry-Pick?

[Andreas Pakulat]

On 31.01.11 16:05:43, Aaron J. Seigo wrote:
> On Monday, January 31, 2011, Thiago Macieira wrote:
> > On Monday, 31 de January de 2011 14:44:38 Aaron J. Seigo wrote:
> > > On Monday, January 31, 2011, Andreas Pakulat wrote:
> > > > something that hasn't been written down as far as I can see (if I
> > > > overlooked it, please point me to it) is what the policy on kdelibs is
> > > > to be now wrt. merging vs. cherry-picking of changes in branches and
> > > > master?
> > > 
> > > what i've started doing for bugfixes is to apply the fix to the stable
> > > branch (e.g. 4.6) and then cherry-pick that into master. when i tried to
> > > merge the 4.6 branch into master, i just got a ton of conflicts, so i
> > > stopped trying that :)
> > 
> > Because of the cherry-picks.
> 
> this was before i did any cherry-picks myself, but perhaps others had already 
> beat me to it. in any case, is there a way to fix it so that the 4.6 branch 
> would become mergeable with master, or do we now basically just have to wait 
> for a 4.7 branch?

One could do a git merge --ours KDE/4.6 if its certain that all changes
from 4.6 have been cherry-picked into master. That'll do the merge, but
ignore any changes in 4.6 and simply always use the master version of
all files. 

Having had a quick look at the result of a normal git merge KDE/4.6 into
master, however I think that this is not desirable. Even some .desktop
files seem to need manual merging (or at least another scripty run, I
can see fr-translations in 4.6 that are not in master). Other things may
be fine, dunno and am not willing to take this on my head by doing the
merge :)

For now I've cherry-picked my change as well (otherwise I might even
forget all about it), but I think trying to do forward-merges at least
when 4.7 branches off would be very useful. I'm constantly doing the
tag --contains and branch --contains thing to find out when a certain
fix was done at work to double-check wether a reported bug is already
contained in a released version. Or which branches are affected by a bug
introduced by a specific commit.

Having this info available for kdelibs is quite important IMHO and hence
worth the extra merge commits in the history. Once you're used to them,
you don't even see them anymore :)

Andreas

-- 
Give him an evasive answer.