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