Thread (1 message) 1 message, 1 author, 2017-08-25

Re: Submodule regression in 2.14?

From: Junio C Hamano <hidden>
Date: 2017-08-25 16:53:43

Heiko Voigt [off-list ref] writes:
On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote:
quoted
On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt [off-list ref] wrote:
quoted
On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:
quoted
On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt [off-list ref] wrote:
quoted
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.



Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help