From: Petr V. <pe...@ya...> - 2013-11-11 09:35:20
|
hi all, can you share your workflow with lxqt repositories, please? I tried to use that "all-in-one" repo with issues. "git pull" behaves strange there. I found that I pull some older code than current one magically. how do you compile all to the latest version? In old razor all was handled automatically because there was only one repo -> all was up to date after one 'git pull'. Now, the build-all.sh script is really inefficient as it runs configure all time and it does not report errors (it just skips them). Or is it better to fetch all repos and build it independently? any advice would be appreciated (I'm not git master;)) thanks, p. |
From: PCMan <pcm...@gm...> - 2013-11-11 09:57:05
|
On Mon, Nov 11, 2013 at 5:35 PM, Petr Vanek <pe...@ya...> wrote: > hi all, > > can you share your workflow with lxqt repositories, please? I tried to > use that "all-in-one" repo with issues. > > "git pull" behaves strange there. I found that I pull some older code > than current one magically. > > Yes, that's the limitation of git. It follows specific commits rather than the latest HEAD. Git 1.7 improved this a little, but it still tracks commits only. > how do you compile all to the latest version? In old razor all was handled automatically because there was only one repo -> all was up to > date after one 'git pull'. Now, the build-all.sh script is really > inefficient as it runs configure all time and it does not report errors > (it just skips them). Currently I'm doing this in the lxde-qt all-in-one repo. git submodule update --init git submodule foreach git checkout master git submodule foreach git pull --rebase Then you'll make all of them up to date. This looks a little bit stupid, though. I'm not a git master, either. So this might not be the best way. At least this is easier in git 1.7+ since git add a new command to do all these for you. > > Or is it better to fetch all repos and build it independently? > Yes, this should be better. The script build_all.sh is a dirty hack I'm using to compile them all from scratch since I tested on many different machines (most are virtual ones), it's boring to do all of them again and again. According to some cmake gurus, we can create a top CMakeLists.txt in lxde-qt repo, and let it build all of the submodules, but I did not really know how to do it correctly. Earlier our friend from KDE suggested that we can try to use the kde buildsystem, but I don't have the time to try it yet. I focus on fixing the components to get a usable desktop now. > any advice would be appreciated (I'm not git master;)) > > thanks, > p. > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: PCMan <pcm...@gm...> - 2013-11-11 16:20:16
|
OK, fonud something exciting. http://www.vogella.com/articles/Git/article.html#submodules_trackbranch With git 1.8.2, the new feature to track branches can fix our broken workflow. I haven't studied how to change our current git setup to adopt the new feature in 1.8.2, but after it's set up, things will be much easier. Cheers! |
From: <chr...@su...> - 2013-11-11 18:37:03
|
Den 11/11/2013 10.57 skrev "PCMan" <pcm...@gm...>: > On Mon, Nov 11, 2013 at 5:35 PM, Petr Vanek <pe...@ya...> wrote: > >> hi all, >> >> can you share your workflow with lxqt repositories, please? I tried to >> use that "all-in-one" repo with issues. >> >> "git pull" behaves strange there. I found that I pull some older code >> than current one magically. >> >> Yes, that's the limitation of git. It follows specific commits rather > than the latest HEAD. > Git 1.7 improved this a little, but it still tracks commits only. > >> how do you compile all to the latest version? In old razor all was > > handled automatically because there was only one repo -> all was up to >> date after one 'git pull'. Now, the build-all.sh script is really >> inefficient as it runs configure all time and it does not report errors >> (it just skips them). > > > Currently I'm doing this in the lxde-qt all-in-one repo. > git submodule update --init > git submodule foreach git checkout master > git submodule foreach git pull --rebase > Then you'll make all of them up to date. This looks a little bit stupid, > though. > I'm not a git master, either. So this might not be the best way. > At least this is easier in git 1.7+ since git add a new command to do all > these for you. > >> >> > Or is it better to fetch all repos and build it independently? >> > Yes, this should be better. > The script build_all.sh is a dirty hack I'm using to compile them all from > scratch since I tested on many different machines (most are virtual ones), > it's boring to do all of them again and again. > According to some cmake gurus, we can create a top CMakeLists.txt in > lxde-qt repo, and let it build all of the submodules, but I did not really > know how to do it correctly. Earlier our friend from KDE suggested that we > can try to use the kde buildsystem, but I don't have the time to try it > yet. I focus on fixing the components to get a usable desktop now. > I'll have a look at a common CMakeLists.txt if nobody else is working on it. I'm no cmake guru, but it should be possible to make something that can build all modules and hopefully only run autogen.sh and configure when necessary. br. Chr. > >> any advice would be appreciated (I'm not git master;)) >> >> thanks, >> p. >> >> >> >> ------------------------------------------------------------------------------ >> November Webinars for C, C++, Fortran Developers >> Accelerate application performance with scalable programming models. >> Explore >> techniques for threading, error checking, porting, and tuning. Get the >> most >> from the latest Intel processors and coprocessors. See abstracts and >> register >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > > |
From: PCMan <pcm...@gm...> - 2013-11-12 17:00:49
|
OK, I did the new git setup so now submodules can track the latest master branches.Please use git >= 1.8.2 to get the new features. To clone the lxde-qt repos as a whole: > git clone https://github.com/lxde/lxde-qt.git > git submodule init > git submodule update --remote If you already have the lxde-qt repo, do the following to update it. > git submodule update --remote Then you should get all of code in every submodules updated, theoratically. Cheers! |
From: <chr...@su...> - 2013-11-14 20:45:21
|
2013/11/11 chr...@su... <chr...@su...> > Den 11/11/2013 10.57 skrev "PCMan" <pcm...@gm...>: > > On Mon, Nov 11, 2013 at 5:35 PM, Petr Vanek <pe...@ya...> wrote: >> >>> hi all, >>> >>> can you share your workflow with lxqt repositories, please? I tried to >>> use that "all-in-one" repo with issues. >>> >>> "git pull" behaves strange there. I found that I pull some older code >>> than current one magically. >>> >>> Yes, that's the limitation of git. It follows specific commits rather >> than the latest HEAD. >> Git 1.7 improved this a little, but it still tracks commits only. >> >>> how do you compile all to the latest version? In old razor all was >> >> handled automatically because there was only one repo -> all was up to >>> date after one 'git pull'. Now, the build-all.sh script is really >>> inefficient as it runs configure all time and it does not report errors >>> (it just skips them). >> >> >> Currently I'm doing this in the lxde-qt all-in-one repo. >> git submodule update --init >> git submodule foreach git checkout master >> git submodule foreach git pull --rebase >> Then you'll make all of them up to date. This looks a little bit stupid, >> though. >> I'm not a git master, either. So this might not be the best way. >> At least this is easier in git 1.7+ since git add a new command to do all >> these for you. >> >>> >>> >> Or is it better to fetch all repos and build it independently? >>> >> Yes, this should be better. >> The script build_all.sh is a dirty hack I'm using to compile them all >> from scratch since I tested on many different machines (most are virtual >> ones), it's boring to do all of them again and again. >> According to some cmake gurus, we can create a top CMakeLists.txt in >> lxde-qt repo, and let it build all of the submodules, but I did not really >> know how to do it correctly. Earlier our friend from KDE suggested that we >> can try to use the kde buildsystem, but I don't have the time to try it >> yet. I focus on fixing the components to get a usable desktop now. >> > > I'll have a look at a common CMakeLists.txt if nobody else is working on > it. I'm no cmake guru, but it should be possible to make something that can > build all modules and hopefully only run autogen.sh and configure when > necessary. > > br. Chr. > > So I've done the first bit of work on this. I've cleaned up the existing CMakeLists.txt a bit. What I've done is: a) Change CMakeLists.txt files to not use CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. The problem with these two variables is that they hold the path to the topmost CMakeLists.txt in your build hierachy. b) Make sure that the names of custom targets are unique. We had a couple of different CMakeLists.txt files doing: add_custom_target(update_translations ...) which leads collisions when they are called from a common master CMakeLists.txt There is now a (very simple) CMakeLists.txt in the master project, and that will build all the cmake projects. Next I will look at calling the automake projects from the master CMakeLists.txt, which, according to my initial googling should be possible. (Hopefully, longterm, we can move the automake stuff to cmake, but I'm not qualified to do so :-( ) I hope I haven't broken too much. About the new git submodule stuff: This is not easy for someone like me who is somewhat git-illiterate... A couple of issues: When I do 'git submodule update --remote' as PCMan suggested, I get a lot of 'detached heads'. It seams that a fetch is done in each submodule, but no update or merge? Is there a way to do the equivalent of a git pull in each submodule? When I commit something in a submodule, say liblxqt, git status in the main module yields something like: 'liblxqt: modified (new commits)', and it seems I have to do a commit in the master module as well. Is that correct? Is there a way to do it in one command? I kinda long for the old razor days when we had one monolithic git module :-) br. Chr. >> >>> any advice would be appreciated (I'm not git master;)) >>> >>> thanks, >>> p. >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> November Webinars for C, C++, Fortran Developers >>> Accelerate application performance with scalable programming models. >>> Explore >>> techniques for threading, error checking, porting, and tuning. Get the >>> most >>> from the latest Intel processors and coprocessors. See abstracts and >>> register >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Lxde-list mailing list >>> Lxd...@li... >>> https://lists.sourceforge.net/lists/listinfo/lxde-list >>> >> >> >> >> ------------------------------------------------------------------------------ >> November Webinars for C, C++, Fortran Developers >> Accelerate application performance with scalable programming models. >> Explore >> techniques for threading, error checking, porting, and tuning. Get the >> most >> from the latest Intel processors and coprocessors. See abstracts and >> register >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> >> |
From: PCMan <pcm...@gm...> - 2013-11-18 22:48:47
|
On Mon, Nov 18, 2013 at 11:28 PM, Александр Соколов <sok...@gm...>wrote: > I'm glad to see, that I'm not alone. > > Sure, I plan to make all modules buildable in build tree and out of tree. > Also I want to rewrite panel, plugin should to build separate of panel. My > nearest target is runner, after that I plan to rewrite panel, panel is a > big work so It takes a lot of time, you can do other modules at this time. > > I really think that the current lxqt-panel code looks good enough. With proper API doc, it should be easy enough to develop new modules. The grid layout works as expected, too. Everything works out of the box and it's a great panel already. What's your plan about the rewrite? To make modules buildable outside the tree, the only thing that need to be done is making parts shared by modules and the panel a lib and add a cmake module for it. > > 2013/11/17 chr...@su... <chr...@su...> > > >> 2013/11/15 Александр Соколов <sok...@gm...> >> >>> @Christian >>> >>> I'm working on cmake too https://github.com/SokoloffA/lxde-qt. My >>> achievements: >>> >>> *XdgQt* https://github.com/SokoloffA/libqtxdg >>> 1. Buildable with build-tree and install mode. >>> 2. Buildable on Qt4 and Qt5. You can use environment variables >>> USE_QT4/USE_QT5 or directly define it as cmake arguments "cmake >>> -DUSE_QT5=On .." By default Qt4 used. >>> 3. Create different .so files for Qt4 and Qt5 >>> 4. Create different config.cmake files >>> /usr/shared/xdgqt4/xdgqt4-config.cmake. Additionally create common config >>> fille /usr/shared/xdgqt/xdgqt-config.cmake >>> 5. Create public headers like "include/xdgqt/XdgActions >>> 6. Used export feature of cmake. >>> >>> *LxQt* https://github.com/SokoloffA/liblxqt >>> 1. Buildable with build-tree and install mode. >>> 2. Buildable on Qt4 and Qt5. You can use environment variables >>> USE_QT4/USE_QT5 or directly define it as cmake arguments "cmake >>> -DUSE_QT5=On .." By default Qt4 used. >>> 3. Create different .so files for Qt4 and Qt5 >>> 4. Create different config.cmake files, plus create common config fille >>> 5. Create public headers like "include/lxqt/lxqtaboutdialog.h and >>> "include/LxQt/AboutDialog" >>> 6. Used export feature of cmake. >>> >>> Lets work together. >>> >> >> Yes, let's do that. I'll have a look at what you've done. What are your >> plans? Do you want to do the same for alle lxqt modules? If so, maybe we >> could split them between us. (I'm probably not as fast as you, as I'm not a >> great CMake expert...) >> >> br. Chr. >> >> >>> >>> >> >>> 2013/11/15 chr...@su... <chr...@su...> >>> >>>> 2013/11/11 chr...@su... <chr...@su...> >>>> >>>>> Den 11/11/2013 10.57 skrev "PCMan" <pcm...@gm...>: >>>>> >>>>> On Mon, Nov 11, 2013 at 5:35 PM, Petr Vanek <pe...@ya...> wrote: >>>>>> >>>>>>> hi all, >>>>>>> >>>>>>> can you share your workflow with lxqt repositories, please? I tried >>>>>>> to >>>>>>> use that "all-in-one" repo with issues. >>>>>>> >>>>>>> "git pull" behaves strange there. I found that I pull some older code >>>>>>> than current one magically. >>>>>>> >>>>>>> Yes, that's the limitation of git. It follows specific commits >>>>>> rather than the latest HEAD. >>>>>> Git 1.7 improved this a little, but it still tracks commits only. >>>>>> >>>>>>> how do you compile all to the latest version? In old razor all was >>>>>> >>>>>> handled automatically because there was only one repo -> all was up to >>>>>>> date after one 'git pull'. Now, the build-all.sh script is really >>>>>>> inefficient as it runs configure all time and it does not report >>>>>>> errors >>>>>>> (it just skips them). >>>>>> >>>>>> >>>>>> Currently I'm doing this in the lxde-qt all-in-one repo. >>>>>> git submodule update --init >>>>>> git submodule foreach git checkout master >>>>>> git submodule foreach git pull --rebase >>>>>> Then you'll make all of them up to date. This looks a little bit >>>>>> stupid, though. >>>>>> I'm not a git master, either. So this might not be the best way. >>>>>> At least this is easier in git 1.7+ since git add a new command to do >>>>>> all these for you. >>>>>> >>>>>>> >>>>>>> >>>>>> Or is it better to fetch all repos and build it independently? >>>>>>> >>>>>> Yes, this should be better. >>>>>> The script build_all.sh is a dirty hack I'm using to compile them all >>>>>> from scratch since I tested on many different machines (most are virtual >>>>>> ones), it's boring to do all of them again and again. >>>>>> According to some cmake gurus, we can create a top CMakeLists.txt in >>>>>> lxde-qt repo, and let it build all of the submodules, but I did not really >>>>>> know how to do it correctly. Earlier our friend from KDE suggested that we >>>>>> can try to use the kde buildsystem, but I don't have the time to try it >>>>>> yet. I focus on fixing the components to get a usable desktop now. >>>>>> >>>>> >>>>> I'll have a look at a common CMakeLists.txt if nobody else is working >>>>> on it. I'm no cmake guru, but it should be possible to make something that >>>>> can build all modules and hopefully only run autogen.sh and configure when >>>>> necessary. >>>>> >>>>> br. Chr. >>>>> >>>>> >>>> So I've done the first bit of work on this. I've cleaned up the >>>> existing CMakeLists.txt a bit. What I've done is: >>>> >>>> a) Change CMakeLists.txt files to not use CMAKE_SOURCE_DIR and >>>> CMAKE_BINARY_DIR. The problem with these two variables is that they hold >>>> the path to the topmost CMakeLists.txt in your build hierachy. >>>> b) Make sure that the names of custom targets are unique. We had a >>>> couple of different CMakeLists.txt files doing: >>>> add_custom_target(update_translations ...) which leads collisions when they >>>> are called from a common master CMakeLists.txt >>>> >>>> There is now a (very simple) CMakeLists.txt in the master project, and >>>> that will build all the cmake projects. >>>> >>>> Next I will look at calling the automake projects from the master >>>> CMakeLists.txt, which, according to my initial googling should be possible. >>>> (Hopefully, longterm, we can move the automake stuff to cmake, but I'm not >>>> qualified to do so :-( ) >>>> >>>> I hope I haven't broken too much. >>>> >>>> About the new git submodule stuff: This is not easy for someone like me >>>> who is somewhat git-illiterate... A couple of issues: >>>> >>>> When I do 'git submodule update --remote' as PCMan suggested, I get a >>>> lot of 'detached heads'. It seams that a fetch is done in each submodule, >>>> but no update or merge? Is there a way to do the equivalent of a git pull >>>> in each submodule? >>>> >>>> When I commit something in a submodule, say liblxqt, git status in the >>>> main module yields something like: 'liblxqt: modified (new commits)', and >>>> it seems I have to do a commit in the master module as well. Is that >>>> correct? Is there a way to do it in one command? >>>> >>>> I kinda long for the old razor days when we had one monolithic git >>>> module :-) >>>> >>>> br. Chr. >>>> >>>> >>>>>> >>>>>>> any advice would be appreciated (I'm not git master;)) >>>>>>> >>>>>>> thanks, >>>>>>> p. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> November Webinars for C, C++, Fortran Developers >>>>>>> Accelerate application performance with scalable programming models. >>>>>>> Explore >>>>>>> techniques for threading, error checking, porting, and tuning. Get >>>>>>> the most >>>>>>> from the latest Intel processors and coprocessors. See abstracts and >>>>>>> register >>>>>>> >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> Lxde-list mailing list >>>>>>> Lxd...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/lxde-list >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> November Webinars for C, C++, Fortran Developers >>>>>> Accelerate application performance with scalable programming models. >>>>>> Explore >>>>>> techniques for threading, error checking, porting, and tuning. Get >>>>>> the most >>>>>> from the latest Intel processors and coprocessors. See abstracts and >>>>>> register >>>>>> >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Lxde-list mailing list >>>>>> Lxd...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/lxde-list >>>>>> >>>>>> >>>> -- >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Razor-qt" group. >>>> For more options, visit this group at >>>> http://groups.google.com/group/razor-qt?hl=en >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Razor-qt" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to raz...@go.... >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Alexander. >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Razor-qt" group. >>> For more options, visit this group at >>> http://groups.google.com/group/razor-qt?hl=en >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Razor-qt" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to raz...@go.... >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Razor-qt" group. >> For more options, visit this group at >> http://groups.google.com/group/razor-qt?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "Razor-qt" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to raz...@go.... >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Best regards, > Alexander. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Razor-qt" group. > For more options, visit this group at > http://groups.google.com/group/razor-qt?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Razor-qt" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to raz...@go.... > For more options, visit https://groups.google.com/groups/opt_out. > |
From: Александр С. <sok...@gm...> - 2013-11-20 03:11:07
|
2013/11/19 PCMan <pcm...@gm...> > > I really think that the current lxqt-panel code looks good enough. > With proper API doc, it should be easy enough to develop new modules. > The grid layout works as expected, too. > Everything works out of the box and it's a great panel already. > What's your plan about the rewrite? > To make modules buildable outside the tree, the only thing that need to be > done is making parts shared by modules and the panel a lib and add a cmake > module for it. > I told about cmake code refactoring. -- Best regards, Alexander. |
From: Luís P. <lui...@gm...> - 2013-11-22 21:21:32
|
On Thu, Nov 14, 2013 at 12:45 PM, chr...@su... <chr...@su...> wrote: > When I do 'git submodule update --remote' as PCMan suggested, I get a lot of > 'detached heads'. It seams that a fetch is done in each submodule, but no > update or merge? Is there a way to do the equivalent of a git pull in each > submodule? what git version are you using ? what;s the result of git submodule status and what are the contents of the .gitmodules file ? -- Luís Pereira |
From: <chr...@su...> - 2013-11-22 21:45:43
|
2013/11/22 Luís Pereira <lui...@gm...> > what git version are you using ? > 1.8.4.2 > what;s the result of git submodule status > Well.. I've deleted the repository since that post, and is now doing git submodule foreach git pull, but if I do a new clone and then git submodule init and git submodule update and git submodule status, right now I get aaecf43e82e8877c7f22dd390432a24b8038a3af compton-conf (heads/master) 1ad4c8f1abe246d236a7aa98bdbcc6a2ddc55da8 libfm (1.1.0-838-g1ad4c8f) 76685eac1595be3f3debdc32c58fbdba2440ac07 liblxqt (heads/master) 9d5a1f79adf4c292a620e5abe39c871d5a27dca6 liblxqt-mount (heads/master) f27fc3f980fda9c764b60b3693429d039bd58939 libqtxdg (heads/master) a3676952d249d635f92b99115ad404ee86db77be libsysstat (heads/master) 3be76f7cfa0ff9473197026cb0f5285bf92e4757 libxdsettings (heads/master) +4051799ce61f4aebc29d7b5824292e5472f56225 lximage-qt (heads/master) +4623a1571b5340b7da12647e976ed82be83c8be0 lxinput-qt (heads/master) c907e2fee6ec324408edbecdd894c3dee2c9a8fc lxmenu-data (heads/master) d2b711e1f998880582e656c37322f56be4f6111e lxqt-about (heads/master) bf6ac7208296190eff6bd50a34d097d7363c36db lxqt-appswitcher (heads/master) 31f69097ada673ccac4e55d8e2128680753c6c43 lxqt-common (heads/master) 23f097486d5ecd70aad4ddf4d3f666dc970b4e56 lxqt-config (heads/master) 2126d96ccf8fa3a2bd24afc5347cb598fd2e6b41 lxqt-globalkeys (heads/master) 561ba62e4c34e657198963983e8f1e4a99d8f0b9 lxqt-lightdm-greeter (heads/master) 6ff2fe36757a9feb181f03f12e59f6aecdf7cfbf lxqt-notificationd (heads/master) 9191d8cdc2c136e5addd25225639c54474f49404 lxqt-openssh-askpass (heads/master) a43b2ff57edd1bed0a6475a59796812a628853b4 lxqt-panel (heads/master) db4913d9c53936773b8f77df5dc64e22570b2c63 lxqt-policykit (heads/master) fcf6f7dd9fb8e083bcd378193bd8e4618f1b672a lxqt-power (heads/master) 3f96402d9709da41232944a49fff99115e24822f lxqt-powermanagement (heads/master) f219a95e00e4fb198b96dca1e11263dd875880bd lxqt-qtplugin (heads/master) 186942a9bc7a284083a7303516d338528b233b4b lxqt-runner (heads/master) 48090addcd894c004135938d8fe15becaaafb02d lxrandr-qt (heads/master) 9d2a0cc93070e82d2ff3830872f9e3fb6cae26e3 lxsession (heads/master) 4f85644f8a0240369035f9ecdfec02ff7a91c0bb menu-cache (heads/master) +7fb8a7ea41ff88573ae87747049b65727c788254 obconf-qt (heads/master) +76f6d060e67ddfff6d778ab36dd88413f28a82a0 pcmanfm-qt (heads/master) If I do git submodule foreach git branch I get: Entering 'compton-conf' * (detached from aaecf43) master Entering 'libfm' * (detached from 1ad4c8f) master Entering 'liblxqt' * (detached from 76685ea) master Entering 'liblxqt-mount' * (detached from 9d5a1f7) master Entering 'libqtxdg' * (detached from f27fc3f) master Entering 'libsysstat' * (detached from a367695) master Entering 'libxdsettings' * (detached from 3be76f7) master Entering 'lximage-qt' * master Entering 'lxinput-qt' * master Entering 'lxmenu-data' * (detached from c907e2f) master Entering 'lxqt-about' * (detached from d2b711e) master Entering 'lxqt-appswitcher' * (detached from bf6ac72) master Entering 'lxqt-common' * (detached from 31f6909) master Entering 'lxqt-config' * (detached from 23f0974) master Entering 'lxqt-globalkeys' * (detached from 2126d96) master Entering 'lxqt-lightdm-greeter' * (detached from 561ba62) master Entering 'lxqt-notificationd' * (detached from 6ff2fe3) master Entering 'lxqt-openssh-askpass' * (detached from 9191d8c) master Entering 'lxqt-panel' * (detached from a43b2ff) master Entering 'lxqt-policykit' * (detached from db4913d) master Entering 'lxqt-power' * (detached from fcf6f7d) master Entering 'lxqt-powermanagement' * (detached from 3f96402) master Entering 'lxqt-qtplugin' * (detached from f219a95) master Entering 'lxqt-runner' * (detached from 186942a) master Entering 'lxrandr-qt' * (detached from 48090ad) master Entering 'lxsession' * (detached from 9d2a0cc) master Entering 'menu-cache' * (detached from 4f85644) master Entering 'obconf-qt' * master Entering 'pcmanfm-qt' * master - but I think the fix is to run git submodule foreach git update master I am getting the hang of it now, I think. I avoid 'git submodule update' but do 'git submodule foreach git pull'. That seems to behave more like what I expect. and what are the contents of the .gitmodules file ? [submodule "libfm"] path = libfm url = https://github.com/lxde/libfm.git branch = master [submodule "menu-cache"] path = menu-cache url = https://github.com/lxde/menu-cache.git branch = master [submodule "liblxqt"] path = liblxqt url = https://github.com/lxde/liblxqt.git branch = master [submodule "libqtxdg"] path = libqtxdg url = https://github.com/lxde/libqtxdg.git branch = master [submodule "lxqt-about"] path = lxqt-about url = https://github.com/lxde/lxqt-about.git branch = master [submodule "lxsession"] path = lxsession url = https://github.com/lxde/lxsession.git branch = master [submodule "lxqt-powermanagement"] path = lxqt-powermanagement url = https://github.com/lxde/lxqt-powermanagement.git branch = master [submodule "pcmanfm-qt"] path = pcmanfm-qt url = https://github.com/lxde/pcmanfm-qt.git branch = master [submodule "libsysstat"] path = libsysstat url = https://github.com/lxde/libsysstat.git branch = master [submodule "liblxqt-mount"] path = liblxqt-mount url = https://github.com/lxde/liblxqt-mount.git branch = master [submodule "lxqt-runner"] path = lxqt-runner url = https://github.com/lxde/lxqt-runner.git branch = master [submodule "lxqt-power"] path = lxqt-power url = https://github.com/lxde/lxqt-power.git branch = master [submodule "lxqt-policykit"] path = lxqt-policykit url = https://github.com/lxde/lxqt-policykit.git branch = master [submodule "lxqt-panel"] path = lxqt-panel url = https://github.com/lxde/lxqt-panel.git branch = master [submodule "lxqt-openssh-askpass"] path = lxqt-openssh-askpass url = https://github.com/lxde/lxqt-openssh-askpass.git branch = master [submodule "lxqt-notificationd"] path = lxqt-notificationd url = https://github.com/lxde/lxqt-notificationd.git branch = master [submodule "lxqt-config"] path = lxqt-config url = https://github.com/lxde/lxqt-config.git branch = master [submodule "lxqt-appswitcher"] path = lxqt-appswitcher url = https://github.com/lxde/lxqt-appswitcher.git branch = master [submodule "obconf-qt"] path = obconf-qt url = https://github.com/lxde/obconf-qt.git branch = master [submodule "lximage-qt"] path = lximage-qt url = https://github.com/lxde/lximage-qt.git branch = master [submodule "lxrandr-qt"] path = lxrandr-qt url = https://github.com/lxde/lxrandr-qt.git branch = master [submodule "lxinput-qt"] path = lxinput-qt url = https://github.com/lxde/lxinput-qt.git branch = master [submodule "lxqt-globalkeys"] path = lxqt-globalkeys url = https://github.com/lxde/lxqt-globalkeys.git branch = master [submodule "lxqt-common"] path = lxqt-common url = https://github.com/lxde/lxqt-common.git branch = master [submodule "lxqt-lightdm-greeter"] path = lxqt-lightdm-greeter url = https://github.com/lxde/lxqt-lightdm-greeter.git branch = master [submodule "libxdsettings"] path = libxdsettings url = https://github.com/lxde/libxdsettings.git branch = master [submodule "compton-conf"] path = compton-conf url = https://github.com/lxde/compton-conf.git branch = master [submodule "lxmenu-data"] path = lxmenu-data url = https://github.com/lxde/lxmenu-data.git branch = master [submodule "lxqt-qtplugin"] path = lxqt-qtplugin url = https://github.com/lxde/lxqt-qtplugin.git branch = master br. Chr. > -- > Luís Pereira > > -- > -- > You received this message because you are subscribed to the Google > Groups "Razor-qt" group. > For more options, visit this group at > http://groups.google.com/group/razor-qt?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Razor-qt" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to raz...@go.... > For more options, visit https://groups.google.com/groups/opt_out. > |
From: Luís P. <lui...@gm...> - 2013-11-25 23:56:46
|
On Fri, Nov 22, 2013 at 1:45 PM, chr...@su... <chr...@su...> wrote: > - but I think the fix is to run > > git submodule foreach git update master > > I am getting the hang of it now, I think. I avoid 'git submodule update' but > do 'git submodule foreach git pull'. That seems to behave more like what I > expect. using: git submodule update --remote --rebase helps. If you are using git >= 1.8.2 (it can track branches) the submodule HEAD will not be detached. --rebase This option is only valid for the update command. Rebase the current branch onto the commit recorded in the superproject. If this option is given, the submodule's HEAD will not be detached. If a merge failure prevents this process, you will have to resolve these failures with git-rebase(1). If the key submodule.$name.update is set to rebase, this option is implicit. -- Luís Pereira |