-1 for anything that has git submodules in it. Didn't we try submodules at one time and it did not work out and was abandoned? Why is this even discussed now? We can do the Apache transition with repositories as they are today and change the workflow or source code organization later, right? Not much sense to reorganize everything at the same time.
Some of our projects don't need apps, some use heavily customized apps instead of the one from Greg's tree, some need just NSH. When one is supporting multiple NuttX-based products, there can be many apps trees, all different or of different versions. We use repo to integrate NuttX with other software. Using repo + submodules would just add extra dimension of complexity for no reason. I don't want to change our company's CI and test systems because of submodules. There is no client to bill for the hours. Best Regards, Juha Niskanen ________________________________ From: Sebastien Lorquet <sebast...@lorquet.fr> Sent: Thursday, December 19, 2019 10:32 AM To: dev@nuttx.apache.org <dev@nuttx.apache.org> Subject: Re: [DISCUSS - NuttX Workflow] Looks really complex to me, if any contributor has to master all of this perfectly to contribute officially. the submodule sync with these specific options is already too much. do you really realize all that has to be memorized just for a hat repo? to put it another way: if you assure me that this hat repo is completely optional and that I will never ever have to use it, I'm okay. let me use my two repos as usual and play with your hat submodules without annoying anyone else. But, if this workflow requires such a complex string of git commands including rebase anytime I have to push anything to the apps or nuttx repo, I dont want to do it. Again just my opinion. But the endless list of complex git commands with additional options is probably a blocker for many other people too. I dont even want to read it all. Sebastien Le 18/12/2019 à 15:20, David Sidrane a écrit : >> what advantage does in fact the submodule method bring? > See below > >> Even with a hat repository that contains two submodules (apps and nuttx), >> you >> will have to send separate pull requests for each submodule, right? > Yes. But they com nit in 1 Atomic operation. > > > Submodules 101 > > This example is with write access on the repo - for committers > > git clone <url to knot> NuttX > cd NuttX > git checkout master > git submodule sync --recursive && git submodule update --init --recursive > > git checkout -b master_add_tof_driver > > cd nuttx > git checkout -b master_add_tof_driver > > #work and commit - rebase on self and remove drabble. > rebase -i master > #reorder, squash and fixup the commits (learn about mv-changes is your > friend) - you will look organized. > > cd apps > git checkout -b master_add_tof_driver > > #work and commit - rebase on self and remove cruft and noise. > rebase -i master > #reorder, squash and fixup the commits (learn about mv-changes it is your > friend) - you will look organized. > > #Build and test locally. > ## AOK > > cd apps > git push origin master_add_tof_driver > > cd nuttx > git push origin master_add_tof_driver > > cd .. (NuttX) > git add nuts apps > git commit "Update NuttX with TOF driver" > > git push origin master_add_tof_driver > > Ok so now (shal simplified to compare them) > > NuttX master shal 0000 point to > \nuttx master shal 2222 > \apps master shal 1111 > > NuttX master_add_tof_driver cccc > \nuttx master shal aaa > \apps master shal bbb > > merge PR from apps to master apps > merge PR from nuttx to master nuttx > > NuttX master shal 0000 point to (still builds and runs) > \nuttx master shal 2222 > \apps master shal 1111 > > But the branch master of the submodules > > \nuttx master shal aaa > \apps master shal bbb > > > merge PR from NuttX to master NuttX (atomic replacement) > NuttX master shal zzzzz point to > \nuttx master shal aaa > \apps master shal bbb > > > > -----Original Message----- > From: Sebastien Lorquet [mailto:sebast...@lorquet.fr] > Sent: Wednesday, December 18, 2019 5:52 AM > To: dev@nuttx.apache.org > Subject: Re: [DISCUSS - NuttX Workflow] > > Wait, > > what advantage does in fact the submodule method bring? > > Even with a hat repository that contains two submodules (apps and nuttx), > you > will have to send separate pull requests for each submodule, right? > > Sebastien > > Le 18/12/2019 à 14:40, Gregory Nutt a écrit : >> On 12/18/2019 4:23 AM, David Sidrane wrote: >>> That is precisely what submodules do:submodules aggregate on a single >>> SHAL N >>> repositories. >>> >>> The problem is: How to have atomic checkout of the correct configuration >>> with >>> out a temporal shift? >>> >>> Please describe how you would do this. Give detailed steps. >> I don't see any difference in versioning with submodules. You have to >> explicitly state the UUID you are using in the submodule (unless there is >> a >> GIT sub-module trick I don't know). >> >> So how would you checkout the correct configuration with sub-modules. >> Seems >> to me that it is the same issue. >> >> I would vote about 18billion minus for this change. But architecture >> designs >> are not justified by blantant expediency. >> >> Let's not go this way. >> >>
