# Nested Repository Risks

## Recursive submodules

Treat every submodule as an independent repository.
For each one, distinguish:

- dirty nested files;
- the parent-recorded revision;
- the checked-out revision;
- local commits that record different nested revisions;
- local and upstream divergence;
- initialized versus unavailable worktree state.

Inspect initialized submodules recursively.
For uninitialized submodules, inventory metadata and the parent-recorded revision; initialize only when authorized execution requires it.

Integrate and verify nested work before updating its parent pointer.
Pushing is out of scope.
Warn when the resulting parent pointer would reference a nested commit unavailable from its remote.

Git subtrees receive ordinary tracked-file conflict analysis.
Do not inspect subtree remotes, split history, pulls, or pushes.

## Linked workspaces

Inspect shared topology, active operations, locks, and target branch occupancy.
Do not inspect unrelated workspace contents unless they can block or alter this synchronization.

A lock is active or stale only after ownership and operation state establish which.
Never remove one merely because it exists.

## Git worktrees with submodules

Git worktrees share refs and object storage while keeping worktree state such as HEAD and index separate.
Git documents submodule support across multiple worktrees as incomplete.
Do not assume nested checkout isolation.

Before modifying a submodule in this topology, establish:

- its worktree-specific Git directory;
- its HEAD and branch ownership;
- sibling worktrees using the same submodule repository;
- active operations or locks in those worktrees.

Conflict resolution is safe when the nested checkout has isolated worktree state, uses detached HEAD or a uniquely owned branch, and no sibling operation collides.
Resolve mechanical collisions without changing work intent.
Ask only when alternatives change work intent or no lossless route is clear.
After resolution, verify the nested commit and update only the intended parent pointer.

## Semantic conflicts

For every predicted or actual conflict, state both intents, dependency impact, proposed semantic result, validation, and confidence.
Never use blanket side selection as a substitute for intent.
A passing test validates a candidate result but cannot choose between plausible behaviors.

## Recovery points

Use a named rollback reference for history rewrites or complex multi-repository integration.
A clean fast-forward needs its original revision recorded.
Dirty content needs a checkpoint commit or temporary snapshot in addition to a revision anchor.

Retain existing and new recovery points until all local work is accounted for, verification passes, and the result is acknowledged.
Then check final state and remove only the recovery points created for this synchronization.