Am 12.09.2014 um 15:58 schrieb Edward Z. Yang:
tl;dr You can't git-new-workdir checkouts which use core.worktree. This is unfortunate because 'git submodule init' uses core.worktree by default, which means you can't recursively git-new-workdir without a hack.In the beginning, the Developer created the remote Git repository and the submodule. mkdir -p remote/sub (cd remote/sub && git init && touch a && git add a && git commit -m "sub init") mkdir remote/top cd remote/top git init git submodule add ../sub git commit -m "top init" cd ../.. And the Developer said, "Let there be a local clone and submodule", and lo, there was a local clone and submodule: git clone remote/top top (cd top && git submodule init && git submodule update) the Developer blessed the working copy, and said "Be fruitful and increase in number with git-new-workdir": git-new-workdir top worktop Unfortunately, this workdir didn't have the submodules initialized. $ ls worktop/sub/ $ Now, the Developer could have run: $ (cd worktop && git submodule init && git submodule update) but the resulting submodule would not have been shared with the original submodule, in the same way that git-new-workdir shared the Git metadata. The Developer sought to create the submodule in its own likeness, but it did not work: $ rmdir worktop/sub && git-new-workdir top/sub worktop/sub fatal: Could not chdir to '../../../sub': No such file or directory What was the Developer's fall from grace? A glance at the config of the original and new submodule shed light on the matter: $ cat top/sub/.git gitdir: ../.git/modules/sub $ cat top/.git/modules/sub/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true worktree = ../../../sub $ cat worktop/sub/.git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true worktree = ../../../sub git-new-workdir sought to reuse the config of top/sub/.git, but this configuration had core.worktree set. For the original checkout, this worked fine, since its location was .git/modules/sub; but for the new workdir, this relative path was nonsense. I do not think there is really a way to make this work with core.worktree. Our saving grace, however, is there is a hack that can make this work: we just need to use the pre-501770e1bb5d132ae4f79aa96715f07f6b84e1f6 style of cloning submodules: git clone remote/top oktop git clone remote/sub oktop/sub (cd oktop && git submodule init && git submodule update) Now recursive git-new-workdir will work.
Thanks for the report and a nice summary.
What's the upshot? I propose two new features: 1. A flag for git submodule update which reverts to the old behavior of making a seperate .git directory rather than collecting them together in the top-level .git/modules
That would play bad with the upcoming recursive submodule update (which needs .git/modules to safely remove a submodule work tree), so I wouldn't want to do that step backwards.
2. Teach git-new-workdir to complain if core.worktree is set in the source config, and how to recursively copy submodules.
I'd prefer pursuing this approach. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
