So I hope that we do not go to far down the github rabbit hole. At this
level. Everytime we have tried to address and agree to the functional
work flow, we get derailed by github technical implementation details.
I think this discussion is relevant still, but we are on edge losing
focus ont he functional workflow and talking only about github
implementation (and have crossed the edge at times).
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?
There are three different concepts being discussed here that I think we
should separate. I know that I get confused about which is which.
1. Two repositories apps/ and nuttx/ -- GOOD
2. One respository with apps/ and nuttx/ as folders -- VERY, VERY BAD
3. Three repositories, apps/, nuttx/ and, say, testing/. Where testing
has the apps/and nuttx/ as submodules -- WORTH CONSIDERING
Number 3 would simply be a mechanization to support the workflow. The
end user would never clone it or need ever be concerned about it in any
way. From the end-user point of view apps/ and nuttx/ are the only
repositories.
I don't know if my understanding of the proposal is correct (I think
I've confused 2 and 3 a couple of times). But I can't imagine a problem
with the testing/ repository that holds sub-modules. The user would not
be impacted by such a thing in any.
If there is no user impact and no smearing of architectural entities,
then I retract bad things I said about sub-modules in any previous
discussion.
Greg
