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.