git-new-workdir submodules interact poorly with core.worktree

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.

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

2. Teach git-new-workdir to complain if core.worktree is set in the
source config, and how to recursively copy submodules.

What do peopl think?

Thanks, Edward

Am 12.09.2014 um 15:58 schrieb Edward Z. Yang:

Thanks for the report and a nice summary.

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.

I'd prefer pursuing this approach.