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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html