Re: [PATCH 3/3] git-checkout.txt: a note about multiple checkout support for submodules

On Sat, Jan 03, 2015 at 04:41:27PM +0700, Nguyễn Thái Ngọc Duy wrote:

The goal seems to be using multiple checkouts to reduce disk space.
But we have not reached an agreement how things should be. There are a
couple options.

 - You may want to keep $SUB repos elsewhere (perhaps in a central
   place) outside $SUPER. This is also true for nested submodules
   where a superproject may be a submodule of another superproject.

 - You may want to keep all $SUB repos in $SUPER/modules (or some
   other place in $SUPER)

 - We could even push it further and merge all $SUB repos into $SUPER
   instead of storing them separately. But that would at least require
   ref namespace enabled.

On top of that, git-submodule.sh expects $GIT_DIR/config to be
per-worktree, at least for the submodule.* part. Here I think we have
two options, either update config.c to also read
$GIT_DIR/config.worktree (which is per worktree) in addition to
$GIT_DIR/config (shared) and store worktree-specific vars in the new
place, or update git-submodule.sh to read/write submodule.* directly
from $GIT_DIR/config.submodule (per worktree).

These take time to address properly. Meanwhile, make a note to the
user that they should not use multiple worktrees in submodule context.

I'd like to describe though how much the glass is full:

If all submodules exist in same paths in all checked-out
commits, and there is no special settings, only
`submodule.<name>.url` is set, then user can inspect, commit
and update the submodule content. Submodules can be either
independedntly initalized with `submodule update --init`
(being a fully independet clone), or checked-out with
`checkout --to` to the submodule worktree.

It is even verified by tests, so does it worth mentioning in
some manpage or at least commit message?

-- 
Max