Re: [PATCH] git-new-workdir: support submodules

[Junio C Hamano <gitster@pobox.com>]

Craig Silverstein <csilvers@khanacademy.org> writes:

>>> Doesn't a submodule checkout keep some state tied to the working
>>> tree in its repository configuration file?
>>
>> Do you mean, in 'config' itself?  If so, I don't see it.  (Though it's
>> possible there are ways to use submodules that do keep working-tree
>> state in the config file, and we just happen not to use those ways.)
>> Here's what my webapp/.git/modules/khan-exercises/config looks like:
>> ---
>> [core]
>>         repositoryformatversion = 0
>>         filemode = true
>>         bare = false
>>         logallrefupdates = true
>>         worktree = ../../../khan-exercises
>> [remote "origin"]
>>         url = http://github.com/Khan/khan-exercises.git
>>         fetch = +refs/heads/*:refs/remotes/origin/*
>> [branch "master"]
>>         remote = origin
>>         merge = refs/heads/master
>>         rebase = true
>> [submodule "test/qunit"]
>>         url = https://github.com/jquery/qunit.git
>> --
>>
>> The only thing that seems vaguely working-tree related is the
>> 'worktree' field, which is the field that motivated me to set up my
>> patch the way it is.

That is the location of the working tree of the top-level
superproject.  Tied to the state of the submodule working tree
appear in [submodule "test/qunit"] part.

In one new-workdir checkout, that submodule may be "submodule
init"ed, while another one, it may not be.

Or one new-workdir checkout's branch may check out a top-level
project from today while the other one may have a top-level project
from two years ago, and between these two checkouts of the top-level
project, the settings of submodule."test/qunit".* variables may have
to be different (perhaps even URL may have to point at two different
repositories, one historical one to grab the state two years ago,
the other current one).

So sharing config between top-level checkouts may not be enough to
"support submodules" (the patch title).