Heiko Voigt <hvo...@hvoigt.net> writes: > On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote: >> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt <hvo...@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 <hvo...@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.
