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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Dec 6, 2014, 12:44 UTC
Message-ID: <5482FA35.40600@web.de>
In-Reply-To: <CACsJy8BWv8U6+sujEj8HgMGmgFJR_YgCroYHcG1jsoGtbVCD7Q@mail.gmail.com>

Am 05.12.2014 um 02:33 schrieb Duy Nguyen:

Show 6 quoted lines

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

Show 18 quoted lines

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

Show 17 quoted lines

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