[PATCHv1] completion: add option '--recurse-submodules' to 'git clone'

[PATCHv1] completion: add option '--recurse-submodules' to 'git clone'

[Chris Packham]

Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
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

Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone'

[Junio C Hamano]

Chris Packham <judge.packham@gmail.com> writes:

> Signed-off-by: Chris Packham <judge.packham@gmail.com>
> ---
> 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
>  		;;

Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone'

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> 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.

Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone'

[Stefan Beller]

On Wed, Jul 27, 2016 at 10:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> 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

Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone'

[Junio C Hamano]

Stefan Beller <sbeller@google.com> 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.

Re: [PATCHv1] completion: add option '--recurse-submodules' to 'git clone'

[Stefan Beller]

On Thu, Jul 28, 2016 at 9:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> 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.
>