On Fri, Aug 25, 2017 at 2:10 AM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote: > 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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 not sure at all, what Junio thought about this. > IMO that would be 'git worktree > clone' or 'git worktree checkout', no? In todays git terminology an > 'add' is something that puts data into the repository / the index. That > is why I was/am confused. I went with current gits: $ git worktree usage: git worktree add [<options>] <path> [<branch>] or: git worktree list [<options>] or: git worktree lock [<options>] <path> or: git worktree prune [<options>] or: git worktree unlock <path> where the 'add' adds a new worktree (my mental emphasis was on the option that says: "Make the new worktree for the submodule, such that in that worktree the submodule feels like the toplevel repository". If 'add' is a bad naming choice, we may want to discuss&deprecate it in a new thread as that is related to the worktree area?) Thanks, Stefan > > Cheers Heiko
