From 8e643ca14f446b84502f38b0e0525174007afd75 Mon Sep 17 00:00:00 2001 From: Jens Lehmann Date: Sat, 11 May 2013 06:56:17 -0700 Subject: [PATCH] Created Submodule use cases (markdown) --- Submodule-use-cases.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 Submodule-use-cases.md diff --git a/Submodule-use-cases.md b/Submodule-use-cases.md new file mode 100644 index 0000000..a822866 --- /dev/null +++ b/Submodule-use-cases.md @@ -0,0 +1,13 @@ +There are different use cases which submodules solve. The following is a list of those I encountered so far (roughly ordered in perceived relevance): +* Content shared between different repos: +E.g. a library developed by you (or your fork of a public one) used in different projects. +* Content managed by somebody else: +E.g. a public library (you do not have push access to) used in your project. +* Large and/or many files: +To avoid the duration and disk cache pressure of examining or updating such data it can be put into a submodule to achieve an effect comparable to a sparse checkout (but which is easier to setup for each clone). Users can then decide if they want to ignore their changes (making commands like status and diff run significantly faster) and/or not updating them each time the commit recorded in the superproject changes. Upstream can provide reasonable defaults for these settings in the .gitmodules file. +* Umbrella projects: +E.g. different (maybe more or less connected) projects which are released together +* Permissions: +Putting sensitive information (e.g. SSH-keys or code under a NDA) into a submodule (which either has no remote or one that isn't public) to avoid accidental exposure of data. + +Please contact me if your use case doesn't fall into one of the above categories so I can update this list. \ No newline at end of file -- 2.26.2