Am 20.04.2012 22:16, schrieb Antonin Hildebrand: > Hi there, > > I'm just solving same problem as described here in the question: > http://stackoverflow.com/questions/4115817/duplicate-submodules-with-git > > I wanted to try proposed solution, but git-new-workdir does not work > in latest release 1.7.10. > > The problem are plaintext .git files pointing to the root > "superproject" .git directory. The script has not been updated to deal > with this new situation. The problem is not the gitfile, but the core.worktree setting. And I don't see how that script can be updated to deal with the new situation. Since 1.7.8 the core.worktree setting is used to point from the submodules .git directory to its work tree. And as git-new-worktree just links the config file, it inherits the core.worktree setting too, so that will always point to the first work tree even when in the new workdir. And if git-new-worktree would change core.worktree, the first work tree will stop working. I'm not sure why git-new-workdir is used here anyways, the only reason I can think of is to save some disk space. So use a regular submodule there and everything should work for you (at the expense of having the same object store on disk twice). But it seems like a check is missing in the git-new-workdir script if the core.worktree setting is used, as it will never do what it is meant to when that is set and doesn't point to the target directory. Maybe something like the patch below? What I worry about is that after this change it will give users who follow the above mentioned recipe a misleading advice, as following it will make the first submodule stop working. But from the perspective of git-new-workdir this change makes sense, and maybe we have to fix the stackoverflow recipe instead ... on the other hand, problems like this could be the avoided if we'd use the "if we reached thru a gitfile, then the working tree is where you found that gitfile" setup logic outlined in http://permalink.gmane.org/gmane.comp.version-control.git/188007 Opinions? ----8<----- Subject: [PATCH] git-new-workdir: Suggest unsetting the core.worktree setting Linking to a repository that has the core.worktree option set can only work when that core.worktree setting already points to the new-workdir. In all other cases strange things will happen, as new-workdir will be overridden by that setting. So just die when that setting is found and tell the user why and that he should remove it. Reported-by: Antonin Hildebrand <antonin@xxxxxxxxxxxxx> Signed-off-by: Jens Lehmann <Jens.Lehmann@xxxxxx> --- contrib/workdir/git-new-workdir | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir index 75e8b25..90cc207 100755 --- a/contrib/workdir/git-new-workdir +++ b/contrib/workdir/git-new-workdir @@ -41,6 +41,14 @@ then " remove from \"$git_dir/config\" to use $0" fi +# don't link to a repository that has core.worktree defined +coreworktree=$(git --git-dir="$git_dir" config --get core.worktree) +if test -n "$coreworktree" +then + die "\"$git_dir\" has core.worktree set to \"$coreworktree\"," \ + " remove from \"$git_dir/config\" to use $0" +fi + # don't link to a workdir if test -h "$git_dir/config" then -- 1.7.10.208.gb5e6d -- 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