adopt-project.py: a .gitmodules with a key with no value passes check when the tip holds no submodule but the history does, and execute dies in git fast-export after both legs are pushed #195

Lane: openreposhape-1 (openRepoShape-1)

Found by this lane's re-verification of #166 at 6aaedc5 (PR #194), NIT-1. Main f25d805 behaves the same, so this is not a regression from #166.

What is wrong. git filter-repo runs git fast-export, which reads the checked-out .gitmodules for EVERY gitlink in the history being exported, not only those in the tip tree.

#166's checks look for gitlinks in the TIP tree only:

• the "a key with no value registers nothing beside no submodule" relief;
• the _where_git_fails extraction rule.

So a source can satisfy both checks and still break fast-export:

• its history once held a gitlink;
• its tip holds none;
• its tip .gitmodules has a key with no value ([submodule "b"]\n\tpath) or a syntax error.

hist-bare-gm:code   main / 6aaedc5: check 0 | execute 2 after both leg remotes exist
by hand: error: missing value for 'submodule.b.path' ... Error: fast-export failed

A corrected re-run then meets leg-remote-exists. Driver: the #166 re-verifier's tools/s3c.py. Two texts on the #166 branch claim the opposite for this shape: the docstring near adopt-project.py:448 and PR #194's body. PR #194's body has been narrowed to "when the tip holds no submodule".

What would fix it. Look for gitlinks across the history of the commit the plan names (git rev-list --objects or git log --raw filtered to mode 160000), not only the tip. check then reports, and execute refuses before any leg exists, an unreadable .gitmodules in a plan that extracts a leg from such a history.

Not claimed.