Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 02.12.2014 um 23:16 schrieb Max Kirillov:
> On Tue, Dec 02, 2014 at 09:45:24PM +0100, Jens Lehmann wrote:
>>> But, while hacking the submodule init I became more
>>> convinced that the modules directory should be common and
>>> submodules in checkout should be a checkouts of the
>>> submodule. Because this is looks like concept of
>>> submodules, that they are unique for the lifetime of
>>> repository, even if they do not exist in all revisions.
>>> And if anybody want to use fully independent checkout
>>> they can be always checked out manually. Actually, after
>>> a submodule is initialized and have a proper gitlink, it
>>> can be updated and inquired regardless of where it points
>>> to.
>>
>> If I understand you correctly you want to put the
>> submodule's common git dir under the superproject's common
>> git dir. I agree that that makes most sense as the
>> default, but having the possibility to use a common git
>> dir for submodule's of different superprojects would be
>> nice to have for some setups, e.g. CI-servers. But that
>> can be added later.
>
> So far there is no separation of .git/config for different
> worktrees. As submodules rely on the config their separation
> cannot be done fully without changing that. So this should
> be really left for some later improvements.

Wow, so the .git/config is shared between all worktrees? I
suspect you have very good reasons for that, but I believe
that'll make multiple work trees surprise the user from time
to time when used with submodules. Because initializing a
submodule in one worktree initializes it in all other
worktrees too (I suspect other users regard "git submodule
init" being a worktree local command too). And setting
"submodule.<name>.update" to "none" will also affect all
other worktrees. But I'd need to have separate settings for
our CI server, e.g. to checkout the sources without the
largish documentation submodule in one test job (=worktree)
while checking out the whole documentation for another job
building the setup in another worktree.

And if I understand the "checkout: reject if the branch is
already checked out elsewhere" thread correctly, I won't be
able to build "master" in two jobs at the same time?

So two reasons against using multiple worktrees on our CI
server to save quite some disk space :-(

>> Thanks. I just didn't quite understand why you had to do so many
>> changes to git-submodule.sh. Wouldn't it be sufficient to just
>> update module_clone()?
>
> Thanks, I should try it.
>
> Probably I had the opposite idea in mind - keep module_clone
> as untouched as possible. Maybe I should see how it's going
> to look if I move all worktrees logic there.

Thanks. But I changed my mind about the details (now that I
know about .git/config and multiple worktrees). I think you'd
have to connect a .git directory in the submodule to the
common git dir directly, as you cannot use the core.worktree
setting (which could be different between commits due to
renames) when putting it into <worktree>/.git/modules. And
then you couldn't remove or rename a submodule anymore,
because that fails when it contains a .git directory.

Seems like we should put a "Warning: may do unexpected things
when used with submodules" (with some examples about what might
happen) in the multiple worktrees documentation. And I don't
believe anymore that teaching submodules to use the common git
dir makes that much sense after I know about the restrictions
it imposes.

Or am I misunderstanding anything?