Re: Submodule regression in 2.14?

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 25, 2017, 16:53 UTC
Message-ID: <xmqqk21rtwq8.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170825091048.GB14872@book.hvoigt.net>

Heiko Voigt <hvoigt@hvoigt.net> writes:

Show 18 quoted lines

> On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote:
>> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
>> > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:
>> >> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
>> >> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:
>> >>     # You feel the superproject is in the way?
>> >>     git worktree add --for-submodule <path/to/sub> ...
>> >>     # The new submodule worktree puts the
>> >>     # submodule only UX first. so it feels like its own
>> >>     # repository, no need for specific flags.
>> >
>> > I am not sure I understand this one. What would that do? Put a worktree
>> > for submodule path/to/sub to ...?
>> 
>> Yes, and at "..." you would have the UX of the submodule being
>> its own repository, no interaction with the superproject.
>
> Are you sure that is what Junio meant?

I am sure it was not.

If adding a separate worktree only for one submodule, you should be able to "cd $path-to-submodule" and run "git worktree add" to create a new worktree, and I do not see any reason for the superproject to get involved in that process. Does it have more information ready than the end user has to help the process of creating a new worktree?

While I can understand how --for-submodule above may be implemented, I do not see the point of adding such an option.