On Wed, Apr 4, 2012 at 7:21 PM, Martin Bagge / brother <[email protected]>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
Thanks
> (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.)
>
> - --
> brother
> http://sis.bthstudent.se
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBCAAGBQJPfC6xAAoJEJbdSEaj0jV70YQH/ArvM93TXY8sR0j4ll4rOMPe
> /lLhlXDYdf0Ch9H4Yzf1CuoZJFeTQChRz0jkFgkfG3h4qW6GI2AQB2HME5EQvMEw
> zBIlZEEElwX1C1L8GPAd6n39cDB9hFT7hzet3XCfaWtt29mSqV+x/OTQxDVP+1Vt
> xXQhCzwv1EK2IfJ+6RbVhUbGOkas7fhsUuNc6tN3ZBkUBhfRJap9i5uA3zT0FC7G
> HnASsy8xCFVfcLp99R5DqZIEfsPgx5FxmpVo40bWDuWZmbkXcTpn4eupbgpIujjl
> nch+x9ucBltOkk3ltGFIHjNRMv8fmo23u0wrY/mzdxlfVBDacODhQlHtFFrmckA=
> =n7kD
> -----END PGP SIGNATURE-----
>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Lxde-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxde-list
