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 <ada...@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