On Wed, Apr 4, 2012 at 7:21 PM, Martin Bagge / brother <brother@bsnet.se> wrote:
Hash: SHA256

On 2012-04-04 13:12, PCMan wrote:
> 2. If I just want to pull your other fixes to my master branch, and
> leave your major UI changes in a separate feature branch, what's the
> better strategy to do it? Git cherry-pick seems to work in this case,
> but it seems to cause future merging problems as well. I'm not that
> familiar with git, so please give some suggestions.

A correct cherry-pick will be indentified and mergable. if the changes
between the branches are too great the merge will fail but that should
not be the case.

Thank you. I haven't use git cherry-pick previously and a google search showed some side effects of it. So I think I need to figure out a better merging strategy prior to doing it.

Probably the easiest would be to have a multitude of branches maintained
(like one per feature with only one or maybe two /small/ commits) and
then rebase to have the same ancestors all the time.
When ready to merge it is as easy as doing "git rebase master; git
checkout master; git merge" - as the rebase will be without real impacts
if the commits are small enough.

The problem is, some of the changes Vadim Ushakov are big enough and touch the UI. Others are small pieces which fixes simple bugs.
I'd like to merge the bug fixes first and leave the UI and string changes and new features for the next release. If you can take a look on this, that's really helpful.
He really gets some nice fixes which I want to pull in very much. Some of the fixes seemed to solve some related problems lying in our bug trackers.


(this coming weekend I will most probably be actively hacking on LXDE
stuff. I am going away to get some peace from other distrubances. main
focus will be to get lxdm and lxpanel going. if you want me to look at a
git strategy for pcmanfm/libfm I probably will find time for that.)

- --
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/