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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html