Module submodule 

Git submodule detection and initialization (issue #50).

git submodule status is a sanctioned subprocess read (spec §4); the parsers live in porcelain. Initialization is a mutating/network operation, so it goes through the git CLI. Both run against a worktree directory: a freshly created worktree (or one switched to a branch that adds submodules) reports its submodules as uninitialized until update --init populates them.

Why a new worktree re-clones everything

A linked worktree does not share the superproject’s submodule object stores. Git resolves a linked worktree’s submodule gitdir to $GIT_COMMON_DIR/worktrees/<id>/modules/<name>, not the shared $GIT_COMMON_DIR/modules/<name>, so a plain update --init --recursive in a new worktree performs a full network clone of every submodule even though byte-identical objects already sit on the same disk.

Two consequences show up here: enumeration has to recurse to be honest about nested submodules, and git worktree remove refuses any worktree that has a populated submodule.

Functions

uninitialized

Returns the paths of submodules that are defined but not yet initialized in worktree_dir (the - marker of git submodule status). Best-effort: a repo with no submodules, or a directory where the command cannot run, yields an empty list rather than an error, so callers can treat “no submodules” and “could not tell” alike.

update_init

Initializes and updates all submodules in worktree_dir, recursively (git submodule update --init --recursive). Propagates a subprocess error; callers decide whether that is fatal.