From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Marc Branchaud <marcnarc@xiplink.com>,
git@vger.kernel.org, Duy Nguyen <pclouds@gmail.com>,
Stefan Beller <sbeller@google.com>
Subject: Re: [PATCH] new-workdir: Never try to recurse into submodules on the initial checkout.
Date: Mon, 14 Jan 2019 13:44:05 -0800 [thread overview]
Message-ID: <xmqqwon6ud7e.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20190114213430.GC162110@google.com> (Jonathan Nieder's message of "Mon, 14 Jan 2019 13:34:30 -0800")
Jonathan Nieder <jrnieder@gmail.com> 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@xiplink.com>
>> ---
>
> 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?
next prev parent reply other threads:[~2019-01-14 21:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 17:27 [PATCH] new-workdir: Never try to recurse into submodules on the initial checkout Marc Branchaud
2019-01-14 21:34 ` Jonathan Nieder
2019-01-14 21:44 ` Junio C Hamano [this message]
2019-01-14 21:58 ` Jonathan Nieder
2019-01-15 15:02 ` Marc Branchaud
2019-01-15 18:38 ` Junio C Hamano
2019-01-15 15:01 ` Marc Branchaud
2019-01-15 15:07 ` [PATCHv2] " Marc Branchaud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqwon6ud7e.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=marcnarc@xiplink.com \
--cc=pclouds@gmail.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).