# [PATCHv1] completion: add option '--recurse-submodules' to 'git clone' 6 messages from 2016-07-27 to 2016-07-29. Participants: Chris Packham, Junio C Hamano, Stefan Beller. Thread: https://gitlist.dev/t/42938 ## Chris Packham, 2016-07-27 08:34 Subject: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone' Message-ID: <20160727083406.10241-1-judge.packham@gmail.com> URL: https://gitlist.dev/e/20160727083406.10241-1-judge.packham%40gmail.com ``` Signed-off-by: Chris Packham --- Hi, I noticed --recurse-submodules was missing from the bash completion. This adds it. I went for '--recurse-submodules' instead of '--recursive' as I seem to recall the former being agreed upon as the better (or least ambiguous) of the two terms. contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 37888f4..7c06455 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1136,6 +1136,7 @@ _git_clone () --depth --single-branch --branch + --recurse-submodules " return ;; -- 2.9.2 ``` ## Junio C Hamano, 2016-07-27 17:21 Subject: Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone' Message-ID: URL: https://gitlist.dev/e/xmqqshuvvvxb.fsf%40gitster.mtv.corp.google.com In-Reply-To: <20160727083406.10241-1-judge.packham@gmail.com> ``` Chris Packham writes: > Signed-off-by: Chris Packham > --- > Hi, > > I noticed --recurse-submodules was missing from the bash completion. This adds > it. I went for '--recurse-submodules' instead of '--recursive' as I seem to > recall the former being agreed upon as the better (or least ambiguous) of the > two terms. Yup, that position is consistent with what 3446a54c (clone: fixup recurse_submodules option, 2011-02-11) gave us. Perhaps we should think about deprecating "--recursive"? I dunno. > contrib/completion/git-completion.bash | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash > index 37888f4..7c06455 100644 > --- a/contrib/completion/git-completion.bash > +++ b/contrib/completion/git-completion.bash > @@ -1136,6 +1136,7 @@ _git_clone () > --depth > --single-branch > --branch > + --recurse-submodules > " > return > ;; ``` ## Junio C Hamano, 2016-07-27 17:32 Subject: Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone' Message-ID: URL: https://gitlist.dev/e/xmqqoa5jvven.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Junio C Hamano writes: >> I noticed --recurse-submodules was missing from the bash completion. This adds >> it. I went for '--recurse-submodules' instead of '--recursive' as I seem to >> recall the former being agreed upon as the better (or least ambiguous) of the >> two terms. > > Yup, that position is consistent with what 3446a54c (clone: fixup > recurse_submodules option, 2011-02-11) gave us. Silly me. The blame actually goes down to ccdd3da6 (clone: Add the --recurse-submodules option as alias for --recursive, 2010-11-04), but the conclusion is the same. > Perhaps we should think about deprecating "--recursive"? I dunno. Anyway, I'll apply the "addition to the completion" patch. Thanks. ``` ## Stefan Beller, 2016-07-27 17:41 Subject: Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone' Message-ID: URL: https://gitlist.dev/e/CAGZ79ka0kvr9RAkGHbgrZ7fery8436dH8Nu4bwG0t3K5FprgKA%40mail.gmail.com In-Reply-To: ``` On Wed, Jul 27, 2016 at 10:32 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >>> I noticed --recurse-submodules was missing from the bash completion. This adds >>> it. I went for '--recurse-submodules' instead of '--recursive' as I seem to >>> recall the former being agreed upon as the better (or least ambiguous) of the >>> two terms. >> >> Yup, that position is consistent with what 3446a54c (clone: fixup >> recurse_submodules option, 2011-02-11) gave us. > > Silly me. The blame actually goes down to ccdd3da6 (clone: Add the > --recurse-submodules option as alias for --recursive, 2010-11-04), > but the conclusion is the same. > >> Perhaps we should think about deprecating "--recursive"? I dunno. > > Anyway, I'll apply the "addition to the completion" patch. > > Thanks. Thanks for this patch! Note: if we ever decide to resurrect sb/submodule-default-path, we run into a merge conflict. The reasoning for using "--recurse-submodules" instead of a plain "--recurse" makes sense as well, so that merge conflict will be resolved in favor of this patch. Thanks, Stefan ``` ## Junio C Hamano, 2016-07-28 16:22 Subject: Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone' Message-ID: URL: https://gitlist.dev/e/xmqqshutspfc.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Stefan Beller writes: >> Anyway, I'll apply the "addition to the completion" patch. >> >> Thanks. > > Thanks for this patch! > > Note: if we ever decide to resurrect sb/submodule-default-path, > we run into a merge conflict. The reasoning for using > "--recurse-submodules" instead of a plain "--recurse" makes sense > as well, so that merge conflict will be resolved in favor of this patch. Thanks for an advance warning. My rerere database has already been taught about this conflict ;-) As to sb/submodule-default-path topic, which has been blocked on still-in-flux attribute work, I am tempted to declare that the attribute work is not yet thread-ready but it is in a good enough shape to base other works on, and have them advance to 'next'. The traditional pattern of allowing the callers to randomly allocate an array of "struct git_attr_check" and passing the pointer to its first element to git_check_attr() function was impossible to extend without having to update the callers, but we have migrated away from the pattern and the attribute subsystem can be enhanced without impacting the callers too much. ``` ## Stefan Beller, 2016-07-29 01:26 Subject: Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone' Message-ID: URL: https://gitlist.dev/e/CAGZ79kbCTQx_FAeGkJRRyDotAsdJT6J%2B4Ab9BHW-YFw6rOqaqQ%40mail.gmail.com In-Reply-To: ``` On Thu, Jul 28, 2016 at 9:22 AM, Junio C Hamano wrote: > Stefan Beller writes: > >>> Anyway, I'll apply the "addition to the completion" patch. >>> >>> Thanks. >> >> Thanks for this patch! >> >> Note: if we ever decide to resurrect sb/submodule-default-path, >> we run into a merge conflict. The reasoning for using >> "--recurse-submodules" instead of a plain "--recurse" makes sense >> as well, so that merge conflict will be resolved in favor of this patch. > > Thanks for an advance warning. My rerere database has already been > taught about this conflict ;-) > > As to sb/submodule-default-path topic, which has been blocked on > still-in-flux attribute work, I am tempted to declare that the > attribute work is not yet thread-ready but it is in a good enough > shape to base other works on, and have them advance to 'next'. I am tempted to ask for delaying sb/submodule-default-path a bit more and see if there is an alternative solution. Inspired by Duys series on submodules and worktree I found a new way how to do the submodule management (separation of the submodule URL as a flag indicating the existence and the actual URL), and that will be very similar to what is implemented in sb/submodule-default-path just even more streamlined. (That said the state of that new series is still vapor and not yet solid, so ... it's hopes and dreams.) > > The traditional pattern of allowing the callers to randomly allocate > an array of "struct git_attr_check" and passing the pointer to its > first element to git_check_attr() function was impossible to extend > without having to update the callers, but we have migrated away from > the pattern and the attribute subsystem can be enhanced without > impacting the callers too much. > ```