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

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

Am 05.12.2014 um 02:33 schrieb Duy Nguyen:
> On Fri, Dec 5, 2014 at 3:06 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Wow, so the .git/config is shared between all worktrees? I
>> suspect you have very good reasons for that,
>
> most of config vars are at repo-level, not worktree-level, except
> maybe submodule.* and something else.

Yeah, that would have been my first guess too.

 > Technically we could use
> "include.path" to point to a non-shared file, where we store
> worktree-specific config.

I like that, but am not sure how hard that would be to
implement.

>> 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?
>
> If you do "git checkout --to ... master^{}", it should run fine.

So I'd have to teach our CI-server that incantation ... and
must hope nothing else breaks because of the detached HEAD.

 > I'm
> still considering doing something better with the read-only refs, but
> haven't found time to really think it through yet.

Hmm, what about different namespaces for the refs in the repo
borrowed from? Maybe only when it is bare? Dunno ...

>> 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.
>
> I'm ok with such a warning fwiw.

I believe you'd need to prominently advertise that changing
settings in .git/config affects all worktrees anyway to avoid
surprising users (at least I didn't expect it ;-), so adding
a word or to that this also impacts submodules should suffice.