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]?
[1]:
https://docs.yoctoproject.org/contributor-guide/submit-changes.html#acceptance-of-ai-generated-code
Best regards,
--
Paul Barker
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#243513):
https://lists.openembedded.org/g/openembedded-core/message/243513
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]]
-=-=-=-=-=-=-=-=-=-=-=-
