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

From: Craig Silverstein <csilvers@khanacademy.org>
Date: Jan 25, 2015, 01:47 UTC
Message-ID: <CAGXKyzEPWrbRFOhvCBm=2Z50zso85G50z-nLd_wyzyeEADQSmw@mail.gmail.com>
In-Reply-To: <xmqqegqlnelu.fsf@gitster.dls.corp.google.com>

} 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 <gitster@pobox.com> wrote:

Show 48 quoted lines

> 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).