Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

From: Stefan Beller <sbeller@google.com>
Date: Jul 22, 2016, 16:07 UTC
Message-ID: <CAGZ79kbMbW9Aex92cFj0oVWMBC0F2z9JDm9QdAO4BQPSSMhDNg@mail.gmail.com>
In-Reply-To: <64e9e8fc-50b3-98d8-fca8-6a70028c6398@web.de>

On Fri, Jul 22, 2016 at 12:32 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:

Show 17 quoted lines

> Am 21.07.2016 um 01:22 schrieb Stefan Beller:
>>
>> So maybe we want to drop that series and first talk about a migration plan
>> from
>> the current state to a world where we have the existence depending not
>> on the url
>> parameter, but a boolean variable submodule.<name>.<good_name>.
>> Depending on <good_name> a submodule would be ignored or tried to checkout
>> in e.g. `submodule update`
>
>
> Whoa, that's a very intrusive change with a ton of compatibility
> problems waiting to happen. Maybe its simpler to make "git submodule
> sync" aware of worktrees and error out with an "you cannot use
> submodules with different URLs in a worktree scenario" error when
> the URL is going to change? That should make most use cases work
> while avoiding the problematic ones.

I think fixing sync alone is just a drop of water on the oven. Actually I can think of scenarios that have different URLs for different worktrees (think of the automatic CI thing that should only fetch from an internal server, whereas the dev-checkout fetches from upstream) Actually each config variable (including the update strategy as you mention below, but also the depth, branch, path) may be different in one work tree.

I do not want to forbid the existence of different settings (URLs) per worktree. Rather I think a different setting is a user decision, hence they will want to run "git config --worktree ..."

And one of the unfortunate things is the coupling of existence of a submodule and the URL. If that were to be decoupled, you could do a "git config --worktree submodule.<name>.exists true" (or it is wrapped fancily in "git submodule init") and the URL would not have to be copied from the .gitmodules file.

I agree that this is a breaking change, which is why I'd guard it with a config option such that the user can make the choice if they want to go with the old behavior or the new behavior.

Show 13 quoted lines

>
>> If we want to move the current behavior of submodules forward, we
>> would want to have
>> anything but the url as shared variables and then use the url variable
>> as a per-worktree
>> existence flag.
>
>
> Without having though deeply about all submodule variables, I see
> them as worktree specific. E.g. "update=none" is used on our CI-
> Server to avoid the disk space cost on some checkouts of a certain
> superproject while using "update=checkout" on others where their
> content is needed.

But this is a conscious user choice, so you would have configured that on a per-worktree basis anyway? i.e. it seems to me as if "update=checkout" is a default that is good for all but one worktree, so why would you want to configure that n times instead of just once as default? The non default behavior is then overwritten in the specific worktree.