Robot Deal Practice: Locate Submodule Dependencies

A buyer receives a robot software repository and finds a directory that seems to contain a required dependency. Before recording the handover as complete, inspect whether that location is represented as a submodule reference and whether its files were separately supplied. The parent repository can identify a dependency commit without incorporating the dependency's complete working files into that tree. This method uses read-only inspection of an authorized copy and reports no actual supplier delivery.

Define which parent state the handover concerns

Record the repository identity, parent revision and form of delivery. A repository checkout, a source archive and a supplier-created bundle can contain different material. Retain the actual package received and its accompanying inventory. Do not assume that a directory visible on a repository website appears with the same contents in every downloadable archive.

Ask which components are required for the agreed software use. A project may mention optional examples as well as essential dependencies. That distinction must come from project or supplier documentation, not from the directory name. The first inventory should identify the question without installing or retrieving missing components automatically.

Read the dependency relationship in the repository

The Git submodule manual explains management of a repository embedded in another repository and the relationship to the recorded subproject state. Read the applicable submodule information with the selected parent revision. A dependency URL is a locator, while the recorded commit identifies a particular intended state; neither should be discarded from the handover note.

Keep repository declarations separate from local checkout conditions. A submodule may be recorded even when its working files have not been initialized in the received copy. Conversely, a populated directory needs its own state check rather than an assumption that every visible file exactly matches the parent's recorded dependency commit.

Use the tree listing to identify what is recorded

The git ls-tree documentation describes listing a tree and the output fields for mode, object type, object name and path. A qualified reviewer can use that information to examine the selected parent's entries. Preserve the relevant entry and its parent revision so another reviewer can interpret the same relationship.

Do not equate a submodule entry with an ordinary directory full of blobs in the parent tree. Record the referenced commit and the associated path, then determine which separately supplied repository or file set is intended to satisfy that dependency. The note should not invent the dependency's contents merely because a reference was found.

Submodule status information can provide further context about an available working copy, but its meaning must be read using the manual and actual state. This inspection does not require initialization, update, remote fetching or checkout changes. Any later retrieval needs its own authorization and source verification rather than being treated as an invisible inventory operation.

Compare recorded dependencies with supplied material

For each required component, identify the supplied location and the evidence connecting it to the recorded dependency state. If it is absent, distinguish missing files from an unavailable reference or an unclear delivery requirement. These lead to different questions for the supplier. An empty local directory alone should not be turned into a claim that the upstream project has been deleted.

Include nested relationships only where they have actually been inspected. A first-level dependency inventory does not establish that every dependency of every component is present. State the traversal scope and leave unexamined relationships visible. Likewise, file presence does not prove that the complete software builds or operates the robot correctly.

Resolve a gap through an explicit handover revision

A supplier clarification should identify the affected component, intended commit and delivery arrangement. Save the clarification with a revised inventory. Do not repair the handover by replacing the recorded dependency with the latest public version simply because that version is easier to obtain. A different revision may change the software relationship being reviewed.

When the required files are later supplied, record the new package identity and the comparison performed. Preserve the earlier gap and its resolution instead of rewriting the original receipt as complete. Technical review of this relationship remains separate from contractual acceptance, licensing interpretation and functional validation.

The original diagrams illustrate dependency references and delivered material without naming a real supplier. Related records are discussed in the robot deal documentation collection and article directory. The submodule references should remain connected to the parent package throughout later review. If the delivery is repackaged into another directory layout, preserve a mapping from the recorded path to the supplied location. Otherwise, a reviewer may mistake a layout change for a different dependency or overlook a missing component hidden behind a familiar directory name. A clear distinction between a recorded dependency and supplied files lets both parties address a specific handover question.