Re: [PATCHv4 1/5] net/lwip: add lwip-external submodule

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]

On Wed, Aug 02, 2023 at 02:03:04PM +0600, Maxim Uvarov wrote:
> On Mon, 31 Jul 2023 at 04:06, Peter Robinson <pbrobinson@gmail.com> wrote:
> 
> > On Fri, Jul 28, 2023 at 7:09 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Jul 27, 2023 at 03:34:48PM +0300, Ilias Apalodimas wrote:
> > >
> > > > Tom, Simon
> > > > are you ok with submodules on this one?
> > >
> > > Still punting on that question and waiting for commentary from
> > > distribution people.
> >
> > I would prefer not to have to deal with submodules unless the required
> > bits were pulled as part of the release tarball process where it
> > wouldn't then matter to distributions.
> >
> > Peter
> >
> 
> Ilias pointed to an interesting alternative which edk2 uses its git
> subtrees.
> Docs:
> https://www.atlassian.com/git/tutorials/git-subtree
> https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt
> 
> Examples:
> git subtree add --prefix lib/lwip/lwip-external
> https://git.savannah.nongnu.org/git/lwip.git master --squash
> $ git log
> commit 83488286d287e53fad1efbfe1d4f5dbf69202f4a (HEAD -> master)
> Merge: 27b050e91d 120e0665c3
> Author: Maxim Uvarov <maxim.uvarov@linaro.org>
> Date:   Wed Aug 2 07:53:17 2023 +0000
> 
>     Merge commit '120e0665c37ec69d46c10fc341e253ae2e69afca' as
> 'lib/lwip/lwip-external'
> 
> commit 120e0665c37ec69d46c10fc341e253ae2e69afca
> Author: Maxim Uvarov <maxim.uvarov@linaro.org>
> Date:   Wed Aug 2 07:53:17 2023 +0000
> 
>     Squashed 'lib/lwip/lwip-external/' content from commit 84fde1ebbf
> 
>     git-subtree-dir: lib/lwip/lwip-external
>     git-subtree-split: 84fde1ebbfe35b3125fc2d89b8a456cbacf148e9
> 
> 
> So it actually plases code of lwip.git into a subdirectory as a git
> commit.  When you do git clone then all sources will be fetched.
> No need for any additional commands after that. I vote for subtree instead
> of plain code copy.

Since I think we could use this to start off on one stable tag and then
merge to the next as they come out (which is likely the cadence we
want), this does seem like the reasonable way forward.  Too late for v5,
but for v6 can you please make sure the doc contains (and an easy way to
test this would be to start with say STABLE_2_1_0_RELEASE and move it up
to STABLE_2_1_3_RELEASE) an example / instructions on how to use subtree
to perform the updates.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]