Christian Mauderer commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5294#note_126174 Moving imported code into a common subdirectory (`contrib`, `external`, ...) sounds reasonable. I personally would prefer to use git submodules. If you search for a bug, you won't have a big import commit and then have to switch to a separate checkout of the upstream code to continue to search for a bug. Instead you can just blame the file directly in the repository. I assume that we would mirror the repos here on our gitlab anyway. So adding RTEMS specific changes on branches wouldn't be a problem. On an update, I can just create a new branch and rebase or cherry-pick the changes. With the FreeBSD method that you described, for an update I would have to import the new version of the code and then search through our history and re-apply all relevant patches manually (and hope that no one changed unrelated files in the same patch). In my experience, that's a lot more effort than a rebase. Of course the disadvantage of submodules is, that it depends on git. If a project uses a different version controll system or if it only publishes releases, we have to create our own git repo for that project to be able to use it as a submodule (or fall back to another method). -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5294#note_126174 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
