Merge or Cherry-Pick?

[Hugo Pereira Da Costa]

Hey,

So, I've followed the thread. Read everything, found it interesting, though 
there are some conflicting oppinions in there.

Now, here is a practical case:
https://bugs.kde.org/show_bug.cgi?id=265271

Its a one line change in workspace/kstyles/oxygen/oxygenstyle.cpp

I want to follow the "merge" path (cause I personnally do not like cherry-
picking, it indeed causes IMO a lot of trouble with history, bisect, etc., 
from my experience with oxygen-gtk)

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).

I do: git merge -X ours toolbuttons
Is that the correct action to take ? 

Then I'm still left with some conflicts. Explicitly:

# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       deleted by us:      ../../kwin/effects/shadow/shadow.desktop
#       deleted by us:      ../../kwin/effects/shadow/shadow_config.desktop
#       deleted by us:      ../../kwin/effects/sharpen/sharpen.desktop
#       deleted by us:      ../../kwin/effects/sharpen/sharpen_config.desktop
#       deleted by us:      ../../kwin/effects/snow/snow.desktop
#       deleted by us:      ../../kwin/effects/snow/snow_config.desktop
#       added by us:        
../../plasma/generic/dataengines/share/backends/kde/contents/code/main.js

Should I git add/rm them as advised ? (again: my patch is safe, has nothing to 
do with any of the above)

Then commit (in my local master), then compile, test, and ultimately push ? 

Thruth is that I already did that (then reset).
The scary part is that I get a super-long commit message after the resolved 
merge. So please confirm/infirm, advise.

Or should I give up and cherry-pick ? (I'd really like not to).


Thiaro ? Aaron ? 

Thanks in advance,

Hugo

> On Thu, Feb 3, 2011 at 6:21 AM, Dawit A <adawit at kde.org> wrote:
> > git config --global push.default tracking
> > 
> > and use the -t or --track option when creating your branches (branch
> > or checkout -b). This way you can 'git push' (no arguments) in the
> > current tracked branch without accidentally pushing your changes in
> > other branches.
> 
> I think this is the default. When I do "git checkout -b somework
> origin/somework" here, it automatically sets up somework to track
> origin/somework. Push by default only operates on the tracking branch,
> i.e. push --all needs to be specified manually.
> 
> Greetings
> Stefan