<commit_before>git-submodule(1)
================

NAME
----
git-submodule - Initialize, update or inspect submodules


SYNOPSIS
--------
[verse]
'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>]
	      [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] deinit [-f|--force] [--] <path>...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
	      [-f|--force] [--rebase|--merge] [--reference <repository>]
	      [--depth <depth>] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
	      [commit] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command>
'git submodule' [--quiet] sync [--recursive] [--] [<path>...]


DESCRIPTION
-----------
Submodules allow foreign repositories to be embedded within
a dedicated subdirectory of the source tree, always pointed
at a particular commit.

They are not to be confused with remotes, which are meant mainly
for branches of the same project; submodules are meant for
different projects you would like to make part of your source tree,
while the history of the two projects still stays completely
independent and you cannot modify the contents of the submodule
from within the main project.
If you want to merge the project histories and want to treat the
aggregated whole as a single project from then on, you may want to
add a remote for the other project and use the 'subtree' merge strategy,
instead of treating the other project as a submodule. Directories
that come from both projects can be cloned and checked out as a whole
if you choose to go that route.

Submodules are composed from a so-called `gitlink` tree entry
in the main repository that refers to a particular commit object
within the inner repository that is completely separate.
A record in the `.gitmodules` (see linkgit:gitmodules[5]) file at the
root of the source tree assigns a logical name to the submodule and
describes the default URL the submodule shall be cloned from.
The logical name can be used for overriding this URL within your
local repository configuration (see 'submodule init').

This command will manage the tree entries and contents of the
gitmodules file for you, as well as inspect the status of your
submodules and update them.
When adding a new submodule to the tree, the 'add' subcommand
is to be used.  However, when pulling a tree containing submodules,
these will not be checked out by default;
the 'init' and 'update' subcommands will maintain submodules
checked out and at appropriate revision in your working tree.
You can briefly inspect the up-to-date status of your submodules
using the 'status' subcommand and get a detailed overview of the
difference between the index and checkouts using the 'summary'
subcommand.


COMMANDS
--------
add::
	Add the given repository as a submodule at the given path
	to the changeset to be committed next to the current
	project: the current project is termed the "superproject".
+
This requires at least one argument: <repository>. The optional
argument <path> is the relative location for the cloned submodule
to exist in the superproject. If <path> is not given, the
"humanish" part of the source repository is used ("repo" for
"/path/to/repo.git" and "foo" for "host.xz:foo/.git").
The <path> is also used as the submodule's logical name in its
configuration entries unless `--name` is used to specify a logical name.
+<commit_msg>submodule doc: reorder introductory paragraphs<commit_after>git-submodule(1)
================

NAME
----
git-submodule - Initialize, update or inspect submodules


SYNOPSIS
--------
[verse]
'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>]
	      [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] deinit [-f|--force] [--] <path>...
'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
	      [-f|--force] [--rebase|--merge] [--reference <repository>]
	      [--depth <depth>] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
	      [commit] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command>
'git submodule' [--quiet] sync [--recursive] [--] [<path>...]


DESCRIPTION
-----------
Inspects, updates and manages submodules.

A submodule allows you to keep another Git repository in a subdirectory
of your repository. The other repository has its own history, which does not
interfere with the history of the current repository. This can be used to
have external dependencies such as third party libraries for example.

When cloning or pulling a repository containing submodules however,
these will not be checked out by default; the 'init' and 'update'
subcommands will maintain submodules checked out and at
appropriate revision in your working tree.

Submodules are composed from a so-called `gitlink` tree entry
in the main repository that refers to a particular commit object
within the inner repository that is completely separate.
A record in the `.gitmodules` (see linkgit:gitmodules[5]) file at the
root of the source tree assigns a logical name to the submodule and
describes the default URL the submodule shall be cloned from.
The logical name can be used for overriding this URL within your
local repository configuration (see 'submodule init').

Submodules are not to be confused with remotes, which are other
repositories of the same project; submodules are meant for
different projects you would like to make part of your source tree,
while the history of the two projects still stays completely
independent and you cannot modify the contents of the submodule
from within the main project.
If you want to merge the project histories and want to treat the
aggregated whole as a single project from then on, you may want to
add a remote for the other project and use the 'subtree' merge strategy,
instead of treating the other project as a submodule. Directories
that come from both projects can be cloned and checked out as a whole
if you choose to go that route.

COMMANDS
--------
add::
	Add the given repository as a submodule at the given path
	to the changeset to be committed next to the current
	project: the current project is termed the "superproject".
+
This requires at least one argument: <repository>. The optional
argument <path> is the relative location for the cloned submodule
to exist in the superproject. If <path> is not given, the
"humanish" part of the source repository is used ("repo" for
"/path/to/repo.git" and "foo" for "host.xz:foo/.git").
The <path> is also used as the submodule's logical name in its
configuration entries unless `--name` is used to specify a logical name.
+
{'fraction_non_alphanumeric': 0.11123771542515311, 'fraction_numerical': 0.0005697194131890044, 'mean_word_length': 3.934645115952214, 'pattern_counts': {'":': 0, '<': 43, '<?xml version=': 0, '>': 43, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1661384', 'n_tokens_mistral': 1977, 'n_tokens_neox': 1858, 'n_words': 993}