On Sat, Jan 04, 2014 at 11:09:15PM +0100, Heiko Voigt wrote: > On Fri, Jan 03, 2014 at 10:06:11AM -0800, W. Trevor King wrote: > > @@ -306,7 +307,14 @@ module_clone() > > echo "gitdir: $rel/$a" >"$sm_path/.git" > > > > rel=$(echo $a | sed -e 's|[^/][^/]*|..|g') > > - (clear_local_git_env; cd "$sm_path" && GIT_WORK_TREE=. git config core.worktree "$rel/$b") > > Why should this line be removed? Is it not needed for correct > worktree <-> repo linking of submodules? > > > + ( > > + clear_local_git_env > > + cd "$sm_path" && > > + GIT_WORK_TREE=. git config core.worktree "$rel/$b" && > > + if test -n "$branch"; then > > + git checkout -f -q -B "$branch" "origin/$branch" && echo "checked out $branch" > > + fi > > + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")" > > } It's not removed, just merged with the branch manipulation that also happens in a clean local environment in $sm_path. Spawning two sequential subshells with the same setup seemed like overkill. > > @@ -861,7 +860,12 @@ Maybe you want to use 'update --init'?")" > > case ";$cloned_modules;" in > > *";$name;"*) > > # then there is no local change to integrate > > - update_module= ;; > > + if test -n "$branch"; then > > + update_module="!git reset --hard -q" > > Does that not put the user in danger of loosing changes? No, because this is only happens for just-cloned modules. The user hasn't had time to make local changes yet. > If submodule.<name>.branch is configured: > > git submodule update > > will checkout the configured branch instead of the sha1? The use case described by Francesco, a submodule maintainer Alice sets up the submodule, which downstream developer Bob want to checkout to a branch. I think that matching the exact commit specified by Alice in Bob's checkout is important, even if the upstream developer Charlie has advanced the referenced branch in the meantime. Shifting the referenced submodule commit should be an explicit decision made by Alice, not a clone-time accident for Bob. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Attachment:
signature.asc
Description: OpenPGP digital signature