> Subject: Re: [PATCH v4 2/5] devtool: Register nested git repos before the
> initial
> commit
>
> On Fri, 2026-07-31 at 09:26 +0000, Jamin Lin wrote:
> > setup_git_repo() is meant to convert a git repo that a recipe unpacks
> > inside S (e.g. via multiple git SRC_URI entries with different
> > destsuffix values) into a regular git submodule, so devtool can later
> > tag branches on it and extract patches from it via finish/update.
> >
> > That detection never actually triggered, because of the order the
> > function ran things in when it had to create the workspace repo itself:
> >
> > 1. 'git init'
> > 2. 'git add -A .' + initial commit <- commits the nested repo as a
> > bare, unregistered gitlink
> > 3. checkout devbranch, tag basetag
> > 4. scan 'git status --porcelain' for still-untracked directories
> > ("?? <dir>/") and convert any that are git repos into submodules
> >
> > By the time step 4 ran, the nested repo had already been swept up by
> > step 2's 'git add -A .': git treats a directory containing its own
> > .git as an embedded repo and stages it as a gitlink pointing at its
> > current HEAD, without registering it as a submodule. Once that gitlink
> > is committed, 'git status --porcelain' reports it as e.g. " M <dir>"
> > (already tracked) rather than "?? <dir>/" (untracked), so step 4's
> > "line.endswith('/')" check could never match it and the conversion to
> > a real submodule silently never happened.
> >
> > There is also a second entry path with the same root cause: when the
> > recipe's top-level source is itself fetched via git://, repodir is
> > already a git repo, so the 'if not .git' block above (init + initial
> > commit) is skipped entirely - and so was the detection that lived
> > inside it. In that case the nested repo instead gets committed as a
> > bare gitlink later, by patch_task_postfunc's 'git add' after do_patch.
> >
> > Fix this by extracting the detection into a helper and calling it
> > before anything can commit the nested repo as a bare gitlink, in both cases:
> > - freshly-created workspace repo: right after 'git init', before
> > 'git add -A .' and the initial commit;
> > - repodir already a git repo: at function entry, before the later
> > 'git add' in patch_task_postfunc.
> > At those points the nested repo is still untracked and reported with a
> > trailing "/", so it is correctly picked up and registered via 'git
> > submodule add'.
> >
> > Nested repos are discovered top-down (so a repo that manages its own
> > submodules via .gitmodules can be skipped rather than descended into),
> > but registered bottom-up (deepest first): a parent's commit recording
> > its child's HEAD must happen after that child is fully finalized,
> > otherwise registering a still-deeper repo afterwards moves the child's
> > HEAD forward again and leaves the parent pointing at a stale revision.
> >
> > Signed-off-by: Jamin Lin <[email protected]>
>
> This commit is doing three things:
> - Refactoring existing code into register_nested_git_submodules()
> - Modifying the refactored code
> - Moving the call site earlier
>
> It's very hard to review this commit and be confident that it is correct. This
> should be split into a two or three logical steps with simpler commit
> messages.
>
> The wall-of-text commit message and comment suggests to me this may be
> generated with AI. Have you read the contributor guide [1]?
>
After I read this contribution guide, will add
AI-Generated: Uses Claud in commit message.
> [1]:
> https://docs.yoctoproject.org/contributor-guide/submit-changes.html#acceptan
> ce-of-ai-generated-code
>
> Best regards,
>
> --
> Paul Barker
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#243583):
https://lists.openembedded.org/g/openembedded-core/message/243583
Mute This Topic: https://lists.openembedded.org/mt/120531854/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
