Changes inside git submodules are not shown, only the "Subproject commit" pointer

[vladar107]

Problem

I work in a meta-repo: the root has no code of its own, just 11 git submodules
(one per service). All real changes happen inside the submodules.

When I run revdiff at the root, or when the Claude Code plugin launches it there
(detect-ref.sh sees uncommitted changes and starts a working-tree review), the
tree lists each submodule as one entry and the diff pane shows only this:

- Subproject commit e4347a2ade4e6be9f80f9b639a92cec6a2e65548
+ Subproject commit 8b9959542690ad9ddf75cdc4f0963779d8b810e0-dirty

There is nothing to annotate, so the review silently covers none of the actual
changes. That is the part that bites: revdiff looks like it worked, the agent
thinks the review happened, and not a single changed line was on screen.

Piping a hand-built diff into revdiff --stdin works around it, but the plugin
flow cannot know to do that: the launcher runs revdiff in the current directory
and has no way to tell that the diff it got is only gitlink pointers.

revdiff v1.12.0, git 2.55.0, macOS.

Where it comes from

revdiff builds the file list from git diff --name-status, and git never expands
submodules there, not even with --submodule=diff. So each submodule is one
160000-mode entry and the per-file diff for it is the one-line pointer change.

Proposed solution

When a --name-status entry is a gitlink, run git inside that submodule and add
the resulting files to the tree with the submodule path as prefix. The base
follows what git diff --submodule=diff already does: pinned SHA against the
submodule's working tree in working-tree mode, the two gitlink SHAs in ref mode.
The existing per-file loading and editor integration keep working unchanged.

Opt-in behind a flag, --recurse-submodules to match git's own naming for the
same behaviour, so nothing changes for repos without submodules.

If you would rather keep the core as is, a smaller option is to teach the
launcher script to notice a gitlink-only diff and fall back to piping a
per-submodule diff into revdiff --stdin. Something like
git submodule foreach --quiet 'git diff --src-prefix=a/$sm_path/ --dst-prefix=b/$sm_path/'
already produces root-relative paths that the stdin parser handles as is.

Happy to do either, or to hear that this is out of scope.

[umputun]

repro'd, and your diagnosis of the cause is right: git diff --name-status gives one gitlink entry per submodule and the per-file diff is the pointer pair.

not adding recursive submodule support. Running git inside each submodule and prefixing paths gets the diff pane working, but the diff pane isn't the whole tool. Blame, untracked files, the history diff body and --all-files all resolve paths against the meta repo and none of them understand a nested repository, so each would need its own submodule-aware branch. That's git-only work with no hg or jj equivalent, sitting in data and UI paths those two also go through, and it isn't worth it for this layout.

the part I do want to fix is narrower than the flag and it's the one you led with. Revdiff treats the pointer rows as ordinary content, so CountChanges scores every submodule 1 add + 1 remove and your 11 show a confident +11 -11, and ReviewFingerprintStable sees plain add/remove rows and returns true, so they can be marked reviewed and the marks survive a reload. Two things have to hold: a gitlink must be explicit in the UI, and it must never count as reviewed source content. How that looks I haven't decided, and it's more work than it sounds, because a dirty submodule whose pointer hasn't moved produces a patch with no index line and no 160000 in it at all, so classifying one needs git metadata the rendered patch doesn't carry. I'll work it out on this issue.

meanwhile, per submodule:

sm=svc-foo
pinned=$(git rev-parse "HEAD:$sm") && (cd "$sm" && revdiff --untracked "$pinned")

the pinned SHA matters. A plain cd "$sm" && revdiff compares against the submodule's own HEAD, so it misses anything you committed inside the submodule past what the superproject pins, and can miss staged changes. Against $pinned you get committed, staged and unstaged, and --untracked adds the rest. The && is there so a failed rev-parse stops rather than handing revdiff an empty base.

I'd skip the foreach pipe. As written it compares each child against its own HEAD, and its unquoted prefixes break on a submodule path with a space. Even after fixing both it isn't recursive, so a dirty nested submodule feeds revdiff another pointer pair and you're back where you started, and without pipefail an upstream failure can leave revdiff reviewing an empty or partial payload.