} 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,
This is also true, but just as much a problem with the 'git new-workdir' script as it existed before my change. It already symlinks the top-level .git/config directory, which lists a remote, submodules, and many other things. Does symlinking the config file for submodules add any new wrinkles, that symlinking the config file for the top-level repository does not? craig On Fri, Jan 23, 2015 at 5:37 PM, Junio C Hamano <gits...@pobox.com> wrote: > Craig Silverstein <csilv...@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). -- 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
