Drop any file to identify it
No upload. No signup. No sending your file halfway across the internet.
We tell you what it is, right here in your browser.
Drop it!
Let go to identify this file.
Couldn't identify this file
Need to convert it? fwip it →
A git submodule is a git repository nested inside another git repository, pinned to a specific commit. .gitmodules is git's manifest of every submodule the project uses: each gets a `[submodule "name"]` section with `path` (where it lives in the parent's tree) and `url` (where to clone it from). The actual commit each submodule is pinned to lives in the parent repo's object database as a special "gitlink" entry, not in this file.
The format is INI-like, with sections wrapped in square brackets. Git rewrites the file when you run `git submodule add <url> <path>`. Both .gitmodules and the submodule pointers (gitlinks) are committed to the repo, so a fresh `git clone --recursive` checks out the parent plus every submodule pinned at the right commit.
Submodules versus alternatives: subtrees (vendor a copy of another repo with full history), monorepos (one repo containing everything), and package managers (npm/Cargo/RubyGems as the source of truth). Submodules are simplest when you genuinely want a separate-history pin to another repo, but they're widely considered awkward for everyday team workflows — easy to forget to update, easy to leave in a detached state, easy to accidentally commit a submodule pointer rollback. Most modern projects prefer package managers or subtrees.