Sebastian Huber commented on a discussion on .gitmodules: https://gitlab.rtems.org/rtems/prequal/rtems-central/-/merge_requests/2#note_108140 > [submodule "external/rtems"] > path = modules/rtems > - url = git://git.rtems.org/sebh/rtems.git > + url = https://gitlab.rtems.org/sebhub/rtems.git The current work flow is like this: 1. Something in rtems-central is changed locally. 2. The files in `modules/rtems` and `modules/rtems-docs` are regenerated. 3. In the modules, patch sets are created and merge requests are issued. 4. Changes are requested, go to 1, otherwise go to 5. 5. The module branches are rebased to main branches (which now include the generated changes from 1). Quite often you have to fix conflicts during the rebase. After rebase, new branches are pushed. 6. Patch sets for rtems-central are created which include submodule updates. 7. A merge request for rtems-central is issued. In theory, you can review the changes in the submodules in the commits updating the submodules. However, since I have to carry about 28 commits around, you would have to spend a lot of time to do this for each merge request. -- View it on GitLab: https://gitlab.rtems.org/rtems/prequal/rtems-central/-/merge_requests/2#note_108140 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
