git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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?

  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).