All of lore.kernel.org
 help / color / mirror / 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

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.