On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam <kaartic.sivaraam@xxxxxxxxx> wrote: > Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@xxxxxxxxx> > --- > Documentation/gitsubmodules.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt > index bf46b0fb5..cb795c6b6 100644 > --- a/Documentation/gitsubmodules.txt > +++ b/Documentation/gitsubmodules.txt > @@ -57,7 +57,7 @@ Submodules can be used for at least two different use cases: > * Size of the git repository: > In its current form Git scales up poorly for large repositories containing > content that is not compressed by delta computation between trees. > - However you can also use submodules to e.g. hold large binary assets > + Therefore you can use submodules to hold large binary assets If this improves readability by a lot, I'd be all for it. But this use case is just exemplary. There are also cases of submodules that do not contain big files, but e.g. have a lengthy history with lots of small files. So I don't know, as I would want to keep emphasized that this is just an example. > and these repositories are then shallowly cloned such that you do not > have a large history locally. > * Transfer size: > -- > 2.16.0.rc0.223.g4a4ac8367 >