Re: [PATCH] new-workdir: Never try to recurse into submodules on the initial checkout.

[Marc Branchaud <marcnarc@xiplink.com>]

On 2019-01-14 4:58 p.m., Jonathan Nieder wrote:
> Hi,
> 
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>> Marc Branchaud wrote:
> 
>>>> The new workdir is empty before the checkout, so attempts to recurse into
>>>> a non-existent submodule directory fail.
>>>>
>>>> Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
>>>> ---
>>>
>>> Thanks for reporting.  Can you describe the error message when it fails
>>> here?
> [...]
>> IOW, at the point in that script where we call "git checkout -f", if
>> we changed it to "git checkout --recurse-submodules -f", what breaks
>> and why?  Shouldn't it succeed instead?
> 
> I think that's a similar question to the one I asked.
> 
> But I have a good guess about what goes wrong.  It's related to the same
> issue as the "git worktree" problem Marc described.
> 
> Inside the superproject's $GIT_DIR, we see
> 
> 	config
> 	modules/
> 		a/
> 			config
> 		b/
> 			config
> 	...
> 
> The question is what to do with the modules/ directory when you have
> multiple working directories making use of the refs and objects from
> this $GIT_DIR.
> 
> In general, the most useful answer is that the additional working
> directories should make use for modules/ from this $GIT_DIR as well.
> After all, each submodule has its own refs and objects, and the same
> motivation that pushes us to share the refs and objects from the
> superproject would drive us to share them in the submodules as well.
> 
> However, if you do this in the most naive way, it will not work.  In
> the config file, there is a core.worktree setting that ensures that
> commands run from a submodule affect the correct working directory.
> Which worktree should it point to?  All of them.
> 
> There's still an obvious "most useful" answer: each submodule should
> contain its own worktrees/ directory with metadata specific to each
> worktree.  This should work fine and is the future work that Marc and
> I alluded to.  Let me call it (*), for later reference.
> 
> Anything done today is papering over the sad truth that that future
> work (*) has not been done yet.
> 
> contrib/workdir is currently naive about all this: it does *not*
> symlink across the modules/ directory, so each workdir gets its own
> independent copy of all the submodules.  Which kind of defeats the
> point of this kind of setup.
> 
> That said, it's better than nothing at all, which is why Marc proposes
> making it not attempt to check out the submodules right away, instead
> permitting the user to make the best of things.  I suppose another
> thing that is missing is a warning message to ensure the user knows
> that once (*) arrives, they need to be ready for it.  (Or not: this is
> contrib/workdir, and there would be no need to make use of it in place
> of "git worktree" once that moment arrives.)
> 
> To reiterate, this is all about papering over (*) not having been
> done.
> 
> Marc, did I understand correctly?

Yup!

I just hope to keep git-new-workdir hobbling along until worktree can 
fully replace it.

I agree with Junio about what should happen when submodule.recurse=true. 
  But that work should be done in worktree instead of git-new-workdir.

		M.

> Thanks,
> Jonathan
>