Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> 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@xxxxxxxxxxx> >> --- > > Thanks for reporting. Can you describe the error message when it fails > here? > >> Until the worktree command supports submodules I've gone back to using the >> git-new-workdir script, but it fails if my config has >> submdodule.recurse=true. > > Oh, dear. In general, the project does a better job at supporting "git > worktree" than "git new-workdir", but I don't blame you about this. > > Noting locally as another vote for getting submodules to play well with > worktrees soon. > > [...] >> contrib/workdir/git-new-workdir | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir >> index 888c34a521..5de1dc3c58 100755 >> --- a/contrib/workdir/git-new-workdir >> +++ b/contrib/workdir/git-new-workdir >> @@ -102,4 +102,4 @@ trap - $siglist >> >> # checkout the branch (either the same as HEAD from the original repository, >> # or the one that was asked for) >> -git checkout -f $branch >> +git -c submodule.recurse=false checkout -f $branch > > nit: can this use "git checkout --no-recurse-submodules" instead > of -c? > > In general, we tend to recommend that kind of option instead of > --config in scripts. I am not sure if either approach makes sense. Wouldn't the ideal endgame to allow recursive checkout if the user wants to have it, but not enable it by default? Stepping back a bit, if the user has recursive checkout configured somewhere valid for this repository (or worktree), shouldn't the initial checkout also recurse and do a "submodule init" if that is necessary before doing so? 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?
