Re: [PATCH v4 2/5] devtool: Register nested git repos before the initial commit

[Paul Barker <paul@pbarker.dev>]

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 <jamin_lin@aspeedtech.com>

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