On Wed, 13 Sept 2023 at 19:14, Tom Rini <tr...@konsulko.com> wrote: > On Wed, Sep 13, 2023 at 11:06:13AM +0100, Peter Robinson wrote: > > > >> Then if for development you need to pull he history of lwip, you > can do it with: > > > >> git pull -s subtree lwip master --allow-unrelated-histories > > > >> (but I think nobody will need this.) > > > >> > > > >> New update of the lwip net/lwip/lwip-external dir will be done with: > > > >> git pull -s subtree lwip master --allow-unrelated-histories > --squash > > > >> Squash commit also has to be git format-patch friendly. > > > >> > > > >> If you are ok with that proposal I will send v9 with the first > patch created with steps above. > > > > > > > > We've gone through this before. The whole purpose of this is not > > > > having to maintain patches. > > > > Simon, instead of "I had problems in the past", can you elaborate a > bit more? > > > > > > > > Tom said he is fine with subtrees instead of submodules and I know > for > > > > a fact EDK2 doesn't have too many issues with submodules. > > > > Their documentation is pretty clear on building and requires > > > > > > > > git clone https://github.com/tianocore/edk2.git > > > > cd edk2 > > > > git submodule update --init > > > > > > > > Perhaps the situation has improved since you had issues? > > > > > > While I don't really care how you solve this technically, I'd > *strongly* > > > be interested for U-Boot to use *unmodified* lwIP sources where an > > > explicit reference to an lwIP commit is used. I'd rather integrate > > > bugfixes for U-Boot into lwIP than having the sources drift apart. > > > > Strongly agree here, we want to use upstream and all the combined > > development and reviews etc rather than forking off and ending up with > > yet another slightly different IP stack. The whole advantage of > > adopting LWIP is the advantage of combined security, features and bugs > > from a wide range of projects :-) > > Yes, this is what I want as well, and why I'm perhaps more agreeable > with the approaches where it's a lot harder for us to start forking > things unintentionally. I gather submodule rather than subtree would be > better for that case? > > -- > Tom >
Yes, submodule will be a much better solution for us. And I also don't think that today there are any issues with submodules. It works well of OE, RPM and DEB builds, distributions should not have problems with it. BR, Maxim.