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

> [Ack, I forgot to cc myself on the original patch so now I can't reply
> to it normally.  Hopefully my workaround doesn't mess up the threading
> too badly.]
>
> Junio C Hamano <gitster <at> pobox.com> writes:
>>
>> Hmmmm, does that mean that the submodule S in the original
>> repository O's working tree and its checkout in the secondary
>> working tree W created from O using git-new-workdir share the same
>> repository location?  More specifically:
>>
>>     O/.git/                 - original repository
>>         O/.git/index            - worktree state in O
>>         O/S                     - submodule S's checkout in O
>>         O/S/.git                - a gitfile pointing to O/.git/modules/S
>>     O/.git/modules/S        - submodule S's repository contents
>>         O/.git/modules/S/config - submodule S's config
>>
>>     W/.git/                 - secondary working tree
>>         W/.git/config           - symlink to O/.git/config
>>         W/.git/index            - worktree state in W (independent of O)
>>     W/S                     - submodule S's checkout in W (independent of O)
>>     W/S/.git                - a gitfile pointing to O/.git/modules/S
>
> Right until the last line.  The .git file holds a relative path (at
> least, it always does in my experience), so W/S/.git will point to
> W/.git/modules/S.
>
> Also, to complete the story, my changes sets the following:
>
>         W/.git/modules/S    - secondary working tree for S
>              W/.git/modules/S/config   - symlink to O/.git/modules/S/config
>              W/.git/modules/S/index    - worktree state in W's S
> (independent of O and O's S)
>
>> 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.
>
>> Wouldn't this change
>> introduce problems by sharing O/.git/modules/S/config between the
>> two checkouts?
>
> It's true that this change does result in sharing that file, so if
> that's problematic then you're right.  I'm afraid I don't know all the
> things that can go into a submodule config file.
>
> (There are other things I don't know as well, such as: do we see .git
> files with 'gitdir: ...' contents only for submodules, or are there
> other ways to create them as well?  Are 'gitdir' paths always
> relative?  Are there special files in .git (or rather .git/modules/S)
> that exist only for submodules and not for 'normal' repos, that we
> need to worry about symlinking?  I apologize for not knowing all these
> git internals, and hope you guys can help point out any gaps that
> affect this patch!)
>
> craig