On Fri, Jul 22, 2016 at 12:32 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > 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. > >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html