From: PCMan <pcm...@gm...> - 2012-05-07 18:23:35
|
Hi all, I just merged some changes done by Vadim Ushakov with git cherry-pick and they are in our git master now. I only merge the ones fixing bugs. Other new features which changes UI will be pulled into a separate branch for new features later. Now we're in a UI freeze state preparing for 1.0 release. Regarding to the thumbnail part, I did not apply them because: 1. I finished a better gnome3-compatible external thumbnailer support. Now libfm reads /usr/share/thumbnailers and generate thumbnails with the external thumbnailers. 2. The cache part and the "look for thumbnails" by fileinfo part requires some more review since that part is more complicated. To test the external thumbnailer thing, see external-thumbnailer branch of libfm. Things like ffmpegthumbnailer won't work since it supports gnome2 and write its config in gconf. A simple new config file put into /usr/share/thunmbnailer can fix this easily. Thanks On Wed, Apr 4, 2012 at 7:31 PM, PCMan <pcm...@gm...> wrote: > > On Wed, Apr 4, 2012 at 7:21 PM, Martin Bagge / brother <br...@bs...>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----- >> > > |