mirrors/git
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'en/sparse-with-submodule-doc'

Browse Source 
The effect of sparse checkout settings on submodules is documented.

* en/sparse-with-submodule-doc:
  git-sparse-checkout: clarify interactions with submodules
This commit is contained in:
Junio C Hamano
2020-06-22 15:55:03 -07:00
parent 9740ef888e e7d7c73249
commit 81be89e0be
1 changed files with 26 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
Documentation/git-sparse-checkout.txt
View File

@ -200,10 +200,32 @@ directory.
SUBMODULES SUBMODULES
---------- ----------
If your repository contains one or more submodules, then those submodules will If your repository contains one or more submodules, then submodules
appear based on which you initialized with the `git submodule` command. If are populated based on interactions with the `git submodule` command.
your sparse-checkout patterns exclude an initialized submodule, then that Specifically, `git submodule init -- <path>` will ensure the submodule
submodule will still appear in your working directory. at `<path>` is present, while `git submodule deinit [-f] -- <path>`
will remove the files for the submodule at `<path>` (including any
untracked files, uncommitted changes, and unpushed history). Similar
to how sparse-checkout removes files from the working tree but still
leaves entries in the index, deinitialized submodules are removed from
the working directory but still have an entry in the index.
Since submodules may have unpushed changes or untracked files,
removing them could result in data loss. Thus, changing sparse
inclusion/exclusion rules will not cause an already checked out
submodule to be removed from the working copy. Said another way, just
as `checkout` will not cause submodules to be automatically removed or
initialized even when switching between branches that remove or add
submodules, using `sparse-checkout` to reduce or expand the scope of
"interesting" files will not cause submodules to be automatically
deinitialized or initialized either.
Further, the above facts mean that there are multiple reasons that
"tracked" files might not be present in the working copy: sparsity
pattern application from sparse-checkout, and submodule initialization
state. Thus, commands like `git grep` that work on tracked files in
the working copy may return results that are limited by either or both
of these restrictions.
SEE ALSO SEE ALSO