threads / discuss / 42938

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

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

## tl;dr

6 messages between Jul 27, 2016 and Jul 29, 2016.

replies: 5people: 3as markdown or json

Chris Packham· Jul 27, 2016, 08:34 UTC · lore

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

Junio C Hamano· Jul 27, 2016, 17:21 UTC · re: Chris Packham · lore

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

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

Show 8 quoted lines

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

Show 15 quoted lines

>  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· Jul 27, 2016, 17:32 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

>> 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· Jul 27, 2016, 17:41 UTC · re: Junio C Hamano · lore

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

On Wed, Jul 27, 2016 at 10:32 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 19 quoted lines

> 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

Junio C Hamano· Jul 28, 2016, 16:22 UTC · re: Stefan Beller · lore

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

Stefan Beller <sbeller@google.com> writes:

Show 10 quoted lines

>> 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· Jul 29, 2016, 01:26 UTC · re: Junio C Hamano · lore

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

On Thu, Jul 28, 2016 at 9:22 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

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

Show 8 quoted lines

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