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

[Jens Lehmann <Jens.Lehmann@web.de>]

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.