Merge or Cherry-Pick?

[Hugo Pereira Da Costa]

On Thursday 03 February 2011 13:04:18 Johannes Sixt wrote:
> Am 2/3/2011 12:15, schrieb Hugo Pereira Da Costa:
> > So I git cloned KDE/4.6 into some local branch (git checkout KDE/4.6; git
> > checkout -b toolbuttons), then fix, then test.
> > 
> > Now I want to merge to the KDE/4.6 branch; thats easy.
> > 
> > Then I want to merge to master (or to some local branch cloned from
> > master and then from there to master). As already announced in this
> > thread, this results in tons of conflicts (notably many .desktop files).
> 
> Before anybody begins to work in this way, someone with sufficient
> knowlege must introduce the first real merge of the 4.6 branch into the
> master branch. The conflicts must be resolved; or it is possible to punt
> by using -s ours.
> 
> As long as this merge did not happen, anyone who wants to use the merge
> workflow is at a loss, unfortunately.
> 
> > I do: git merge -X ours toolbuttons
> > Is that the correct action to take ?
> 
> No. Perhaps you meant 'git merge -s ours toolbuttons',

No, I really meant

 git merge -X ours toolbuttons

which I believe, is equivalent to 

  git merge -s recursive -X ours toolbuttons

and which, according to the documentation (and confirmed by my test), would 
pick my changes if there is no conflict, and keep the "master" branch source, 
in case of conflict. 

Which, in my case, is exactly what I need (since there is no conflict with 
oxygenstyle.cpp).

Anyway, I agree with you, I'm not that confident with the merge part itself, 
and will follow your advice, by just waiting. 

My understanding is also that people should refrain from cherry-picking before 
this original merge happens, cause that would only make it more painful. 

Correct ?



> but even that would
> be wrong because it would ignore your changes that you made in the 4.6
> branch - but this defeats the purpose of the merge.
> 
> > Or should I give up and cherry-pick ? (I'd really like not to).
> 
> My recommendation: Keep the fix in 4.6 only for the moment. Just wait
> until the initial merge has happened - and lets hope (HOPE BIG TIME) that
> the person doing that merge knows what s/he is doing!
> 
> Hannes