patch, 7 partscompletion bash: add more options and commands

> Managing recorded resolutions requires command-line usage of git-rerere.
> Added subcommand completion for rerere and path completion for its
> subcommand forget.
> ---
>  contrib/completion/git-completion.bash | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index c54a557..8329f09 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2401,6 +2401,17 @@ _git_replace ()
>  	__gitcomp_nl "$(__git_refs)"
>  }
>  
> +_git_rerere ()
> +{
> +	local subcommands="clear forget diff remaining status gc"
> +	local subcommand="$(__git_find_on_cmdline "$subcommands")"
> +	if test -z "$subcommand"
> +	then
> +		__gitcomp "$subcommands"
> +		return
> +	fi
> +}
> +
>  _git_reset ()
>  {
>  	__git_has_doubledash && return
> -- 
> 2.10.2

> You didn't add 'rerere' to the list of porcelain commands, i.e. it
> won't be listed after 'git <TAB><TAB>'.  I'm not saying it should be
> listed there, because I can't decide whether 'rerere' is considered
> porcelain or plumbing...  Just wanted to make sure that this omission
> was intentional.

> ---
>  contrib/completion/git-completion.bash | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 652c7e2..36fe439 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1449,6 +1449,12 @@ _git_ls_files ()
>  
>  _git_ls_remote ()
>  {
> +	case "$cur" in
> +	--*)
> +		__gitcomp "--heads --tags --refs --get-url"
> +		return
> +		;;
> +	esac
>  	__gitcomp_nl "$(__git_remotes)"
>  }
>  
> -- 
> 2.10.2

>> In
>> addition to the existing remote name completions, do also complete
>> the options --heads, --tags, --refs, and --get-url.
> 
> Why only these four options and not the other four?
> 
> There are eight options in total here, so there is really no chance
> for cluttered terminals, and all eight are mentioned in the synopsis.

> On 02/02/2017 02:40 AM, SZEDER Gábor wrote:
>> 
>>> ls-remote needs to complete remote names and its own options.
>> 
>> And refnames, too.
>
> Yes, right. However, do you think it is reasonable to complete remote
> refnames? I don't think so, because it would mean we would have to run
> ls-remote during completion -- and waiting for ls-remote could be quite
> lengthy.

> AFAIR, it was a deliberate decision that potentially destructive command
> line options are not included in command completions. In the list given,
> I find these:
>
>>  - reset: --merge --mixed --hard --soft --patch --keep

>> Please study item (5) "Sign your work" in
>> Documentation/SubmittingPatches and sign off your work.
>
> I followed the recommendations to submitting work, and in the first
> round signing is discouraged.

> Cornelius Weig <cornelius.weig@tngtech.com> writes:
> 
>>> Please study item (5) "Sign your work" in
>>> Documentation/SubmittingPatches and sign off your work.
>>
>> I followed the recommendations to submitting work, and in the first
>> round signing is discouraged.
> 
> Just this point.  You found a bug in our documentation if that is
> the case; it should not be giving that impression to you.  
> 

> On 01/25/2017 12:24 AM, Junio C Hamano wrote:
>> Cornelius Weig <cornelius.weig@tngtech.com> writes:
>>
>>>> Please study item (5) "Sign your work" in
>>>> Documentation/SubmittingPatches and sign off your work.
>>>
>>> I followed the recommendations to submitting work, and in the first
>>> round signing is discouraged.
>>
>> Just this point.  You found a bug in our documentation if that is
>> the case; it should not be giving that impression to you.
>>
>
> Well, I am referring to par. (4) of Documentation/SubmittingPatches
> (emphasis mine):
>
> <<<<<<<<<<<<<<
> *Do not PGP sign your patch, at least for now*.  Most likely, your
> maintainer or other people on the list would not have your PGP
> key and would not bother obtaining it anyway.  Your patch is not
> judged by who you are; a good patch from an unknown origin has a
> far better chance of being accepted than a patch from a known,
> respected origin that is done poorly or does incorrect things.
>>>>>>>>>>>>>>>
>
> If first submissions should be signed as well, then I find this quite
> misleading.
>

> On Tue, Jan 24, 2017 at 3:33 PM, Cornelius Weig
> <cornelius.weig@tngtech.com> wrote:
>> On 01/25/2017 12:24 AM, Junio C Hamano wrote:
>>> Cornelius Weig <cornelius.weig@tngtech.com> writes:
>>>
>>>>> Please study item (5) "Sign your work" in
>>>>> Documentation/SubmittingPatches and sign off your work.
>>>>
>>>> I followed the recommendations to submitting work, and in the first
>>>> round signing is discouraged.
>>>
>>> Just this point.  You found a bug in our documentation if that is
>>> the case; it should not be giving that impression to you.
>>>
>>
>> Well, I am referring to par. (4) of Documentation/SubmittingPatches
>> (emphasis mine):
>>
>> <<<<<<<<<<<<<<
>> *Do not PGP sign your patch, at least for now*.  Most likely, your
>> maintainer or other people on the list would not have your PGP
>> key and would not bother obtaining it anyway.  Your patch is not
>> judged by who you are; a good patch from an unknown origin has a
>> far better chance of being accepted than a patch from a known,
>> respected origin that is done poorly or does incorrect things.
>> <<<<<<<<<<<<<<
>>
>> If first submissions should be signed as well, then I find this quite
>> misleading.
>>
> 
> Please read on; While this part addresses PGP signing,
> which is discouraged at any round,
> later on we talk about another type of signing.
> (not cryptographic strong signing, but signing the intent;)
> the DCO in the commit message.
> 
> So no PGP signing (in any round of the patch).
> 
> But DCO signed (in anything that you deem useful for the
> project and that you are allowed to contribute)
> 

>>
>>> Do not PGP sign your patch, at least *for now*. (...)
>>
> 
> And maybe these 2 small words are the bug in the documentation?
> Shall we drop the "at least for now" part, like so:
> 
> ---8<---
> From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001
> From: Stefan Beller <sbeller@google.com>
> Date: Tue, 24 Jan 2017 16:19:13 -0800
> Subject: [PATCH] SubmittingPatches: drop temporal reference for PGP signing
> 
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>  Documentation/SubmittingPatches | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 08352deaae..28da4ad2d4 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -216,12 +216,12 @@ that it will be postponed.
>  Exception:  If your mailer is mangling patches then someone may ask
>  you to re-send them using MIME, that is OK.
>  
> -Do not PGP sign your patch, at least for now.  Most likely, your
> -maintainer or other people on the list would not have your PGP
> -key and would not bother obtaining it anyway.  Your patch is not
> -judged by who you are; a good patch from an unknown origin has a
> -far better chance of being accepted than a patch from a known,
> -respected origin that is done poorly or does incorrect things.
> +Do not PGP sign your patch. Most likely, your maintainer or other
> +people on the list would not have your PGP key and would not bother
> +obtaining it anyway. Your patch is not judged by who you are; a good
> +patch from an unknown origin has a far better chance of being accepted
> +than a patch from a known, respected origin that is done poorly or
> +does incorrect things.
>  
>  If you really really really really want to do a PGP signed
>  patch, format it as "multipart/signed", not a text/plain message
> 

> On Tue, Jan 24, 2017 at 4:21 PM, Stefan Beller <sbeller@google.com> wrote:
> >
> > +Do not PGP sign your patch. Most likely, your maintainer or other
> > +people on the list would not have your PGP key and would not bother
> > +obtaining it anyway.
> 
> I think even that could be further simplified - by just removing all
> comments about pgp email
> 
> Because it's not that the PGP keys would be hard to get, it's that
> PGP-signed email is an abject failure, and nobody sane does it.
> 
> Google for "phil zimmerman doesn't use pgp email".
> 
> It's dead. So I'm not sure it's worth mentioning at all.

>>
>>> Do not PGP sign your patch, at least *for now*. (...)
>>
>
> And maybe these 2 small words are the bug in the documentation?
> Shall we drop the "at least for now" part, like so:
>
> ---8<---
> From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001
> From: Stefan Beller <sbeller@google.com>
> Date: Tue, 24 Jan 2017 16:19:13 -0800
> Subject: [PATCH] SubmittingPatches: drop temporal reference for PGP 
> signing
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> Documentation/SubmittingPatches | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/SubmittingPatches 
> b/Documentation/SubmittingPatches
> index 08352deaae..28da4ad2d4 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -216,12 +216,12 @@ that it will be postponed.
> Exception:  If your mailer is mangling patches then someone may ask
> you to re-send them using MIME, that is OK.
>
> -Do not PGP sign your patch, at least for now.  Most likely, your
> -maintainer or other people on the list would not have your PGP
> -key and would not bother obtaining it anyway.  Your patch is not
> -judged by who you are; a good patch from an unknown origin has a
> -far better chance of being accepted than a patch from a known,
> -respected origin that is done poorly or does incorrect things.
> +Do not PGP sign your patch. Most likely, your maintainer or other
> +people on the list would not have your PGP key and would not bother
> +obtaining it anyway. Your patch is not judged by who you are; a good
> +patch from an unknown origin has a far better chance of being accepted
> +than a patch from a known, respected origin that is done poorly or
> +does incorrect things.

>> -Do not PGP sign your patch, at least for now.  Most likely, your
>> -maintainer or other people on the list would not have your PGP
>> -key and would not bother obtaining it anyway.  Your patch is not
>> -judged by who you are; a good patch from an unknown origin has a
>> -far better chance of being accepted than a patch from a known,
>> -respected origin that is done poorly or does incorrect things.
>> +Do not PGP sign your patch. Most likely, your maintainer or other
>> +people on the list would not have your PGP key and would not bother
>> +obtaining it anyway. Your patch is not judged by who you are; a good
>> +patch from an unknown origin has a far better chance of being accepted
>> +than a patch from a known, respected origin that is done poorly or
>> +does incorrect things.
>
>
> Wouldn't this also benefit from a forward reference to the section 5 on the
> DOC signining? This would avoid Cornelius's case where he felt that section
> 5 no longer applied.

>
>>
>> Yeah I agree. My patch was not the best shot by far.
>>
>
> How about something along these lines? Does the forward reference
> break the main line of thought too severly?
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 08352de..c2b0cbe 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -216,12 +216,12 @@ that it will be postponed.
>  Exception:  If your mailer is mangling patches then someone may ask
>  you to re-send them using MIME, that is OK.
>
> -Do not PGP sign your patch, at least for now.  Most likely, your
> -maintainer or other people on the list would not have your PGP
> -key and would not bother obtaining it anyway.  Your patch is not
> -judged by who you are; a good patch from an unknown origin has a
> -far better chance of being accepted than a patch from a known,
> -respected origin that is done poorly or does incorrect things.
> +Do not PGP sign your patch, but do sign-off your work as explained in (5).
> +Most likely, your maintainer or other people on the list would not have your
> +PGP key and would not bother obtaining it anyway. Your patch is not judged by
> +who you are; a good patch from an unknown origin has a far better chance of
> +being accepted than a patch from a known, respected origin that is done poorly
> +or does incorrect things.
>
>  If you really really really really want to do a PGP signed
>  patch, format it as "multipart/signed", not a text/plain message
> @@ -246,7 +246,7 @@ patch.
>       *2* The mailing list: git@vger.kernel.org
>
>
> -(5) Sign your work
> +(5) Certify your work by signing off
>
>  To improve tracking of who did what, we've borrowed the
>  "sign-off" procedure from the Linux kernel project on patches

> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 08352de..c2b0cbe 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -216,12 +216,12 @@ that it will be postponed.
>  Exception:  If your mailer is mangling patches then someone may ask
>  you to re-send them using MIME, that is OK.
>  
> -Do not PGP sign your patch, at least for now.  Most likely, your
> -maintainer or other people on the list would not have your PGP
> -key and would not bother obtaining it anyway.  Your patch is not
> -judged by who you are; a good patch from an unknown origin has a
> -far better chance of being accepted than a patch from a known,
> -respected origin that is done poorly or does incorrect things.
> +Do not PGP sign your patch, but do sign-off your work as explained in (5).
> +Most likely, your maintainer or other people on the list would not have your
> +PGP key and would not bother obtaining it anyway. Your patch is not judged by
> +who you are; a good patch from an unknown origin has a far better chance of
> +being accepted than a patch from a known, respected origin that is done poorly
> +or does incorrect things.
>  
>  If you really really really really want to do a PGP signed
>  patch, format it as "multipart/signed", not a text/plain message
> @@ -246,7 +246,7 @@ patch.
>       *2* The mailing list: git@vger.kernel.org
>  
>  
> -(5) Sign your work
> +(5) Certify your work by signing off
>  
>  To improve tracking of who did what, we've borrowed the
>  "sign-off" procedure from the Linux kernel project on patches

> Cornelius Weig <cornelius.weig@tngtech.com> writes:
>
>> How about something along these lines? Does the forward reference
>> break the main line of thought too severly?
>
> I find it a bit distracting for those who know PGP signing has
> nothing to do with signing off your patch, but I think that is OK
> because they are not the primary target audience of this part of the
> document.

>
> I however am more worried that it may be misleading to mention these
> two in the same sentence.  Those who skim these paragraphs without
> knowing the difference between the two may get a false impression
> that these two may somehow be related because they are mentioned in
> the same sentence.
>
> The retitling of section (5) you did, without any other change,
> might be sufficient.  It may also help to be even more explicit in
> the updated title, i.e. s/by signing off/by adding Signed-off-by:/

>
> Thanks.
>
>> diff --git a/Documentation/SubmittingPatches 
>> b/Documentation/SubmittingPatches
>> index 08352de..c2b0cbe 100644
>> --- a/Documentation/SubmittingPatches
>> +++ b/Documentation/SubmittingPatches
>> @@ -216,12 +216,12 @@ that it will be postponed.
>>  Exception:  If your mailer is mangling patches then someone may ask
>>  you to re-send them using MIME, that is OK.
>>
>> -Do not PGP sign your patch, at least for now.  Most likely, your
>> -maintainer or other people on the list would not have your PGP
>> -key and would not bother obtaining it anyway.  Your patch is not
>> -judged by who you are; a good patch from an unknown origin has a
>> -far better chance of being accepted than a patch from a known,
>> -respected origin that is done poorly or does incorrect things.
>> +Do not PGP sign your patch, but do sign-off your work as explained in 
>> (5).
>> +Most likely, your maintainer or other people on the list would not have 
>> your
>> +PGP key and would not bother obtaining it anyway. Your patch is not 
>> judged by
>> +who you are; a good patch from an unknown origin has a far better chance 
>> of
>> +being accepted than a patch from a known, respected origin that is done 
>> poorly
>> +or does incorrect things.
>>
>>  If you really really really really want to do a PGP signed
>>  patch, format it as "multipart/signed", not a text/plain message
>> @@ -246,7 +246,7 @@ patch.
>>       *2* The mailing list: git@vger.kernel.org
>>
>>
>> -(5) Sign your work
>> +(5) Certify your work by signing off
>>
>>  To improve tracking of who did what, we've borrowed the
>>  "sign-off" procedure from the Linux kernel project on patches
> 

> From: "Junio C Hamano" <gitster@pobox.com>
>> Cornelius Weig <cornelius.weig@tngtech.com> writes:
>>
>>> How about something along these lines? Does the forward reference
>>> break the main line of thought too severly?
>>
>> I find it a bit distracting for those who know PGP signing has
>> nothing to do with signing off your patch, but I think that is OK
>> because they are not the primary target audience of this part of the
>> document.
> 
> Agreed. I this case the target audience was those weren't aware of that.

> 
> Maybe even s/by signing off/by adding your Signed-off-by:/ to be sure
> that the reader knows that it is _their certification_ that is being
> sought. Even if it does double up on the 'your'.
> 

>> Maybe even s/by signing off/by adding your Signed-off-by:/ to be sure
>> that the reader knows that it is _their certification_ that is being
>> sought. Even if it does double up on the 'your'.
>
> I don't think doubling on the 'your' will make the heading clearer. The
> main intention of this change is to avoid mixups with pgp-signing and
> that would IMHO not improve by that.
> Besides, I find the colon in the heading a bit awkward. Is the following
> version as expressive as with the colon?
>
> -(5) Sign your work
> +(5) Certify your work by adding Signed-off-by

>  - apply: --recount --directory=
>  - archive: --output
>  - branch: --column --no-column --sort= --points-at
>  - clone: --no-single-branch --shallow-submodules
>  - commit: --patch --short --date --allow-empty
>  - describe: --first-parent
>  - fetch, pull: --unshallow --update-shallow
>  - fsck: --name-objects
>  - grep: --break --heading --show-function --function-context
>          --untracked --no-index
>  - mergetool: --prompt --no-prompt
>  - reset: --keep
>  - revert: --strategy= --strategy-option=
>  - rm: --force

>  - shortlog: --email
>  - tag: --merged --no-merged --create-reflog
>
> Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
> Helped-by: Johannes Sixt <j6t@kdbg.org>
> ---
>  contrib/completion/git-completion.bash | 31 +++++++++++++++++++++----------
>  1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 0e09519..933bb6e 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -936,6 +936,7 @@ _git_apply ()
>                         --apply --no-add --exclude=
>                         --ignore-whitespace --ignore-space-change
>                         --whitespace= --inaccurate-eof --verbose
> +                       --recount --directory=
>                         "
>                 return
>         esac
> @@ -974,7 +975,7 @@ _git_archive ()
>         --*)
>                 __gitcomp "
>                         --format= --list --verbose
> -                       --prefix= --remote= --exec=
> +                       --prefix= --remote= --exec= --output
>                         "
>                 return
>                 ;;
> @@ -1029,6 +1030,7 @@ _git_branch ()
>                         --track --no-track --contains --merged --no-merged
>                         --set-upstream-to= --edit-description --list
>                         --unset-upstream --delete --move --remotes
> +                       --column --no-column --sort= --points-at
>                         "
>                 ;;
>         *)
> @@ -1142,6 +1144,8 @@ _git_clone ()
>                         --single-branch
>                         --branch
>                         --recurse-submodules
> +                       --no-single-branch
> +                       --shallow-submodules
>                         "
>                 return
>                 ;;
> @@ -1183,6 +1187,7 @@ _git_commit ()
>                         --reset-author --file= --message= --template=
>                         --cleanup= --untracked-files --untracked-files=
>                         --verbose --quiet --fixup= --squash=
> +                       --patch --short --date --allow-empty
>                         "
>                 return
>         esac
> @@ -1201,7 +1206,7 @@ _git_describe ()
>         --*)
>                 __gitcomp "
>                         --all --tags --contains --abbrev= --candidates=
> -                       --exact-match --debug --long --match --always
> +                       --exact-match --debug --long --match --always --first-parent
>                         "
>                 return
>         esac
> @@ -1284,6 +1289,7 @@ __git_fetch_recurse_submodules="yes on-demand no"
>  __git_fetch_options="
>         --quiet --verbose --append --upload-pack --force --keep --depth=
>         --tags --no-tags --all --prune --dry-run --recurse-submodules=
> +       --unshallow --update-shallow
>  "
>
>  _git_fetch ()
> @@ -1333,7 +1339,7 @@ _git_fsck ()
>         --*)
>                 __gitcomp "
>                         --tags --root --unreachable --cache --no-reflogs --full
> -                       --strict --verbose --lost-found
> +                       --strict --verbose --lost-found --name-objects
>                         "
>                 return
>                 ;;
> @@ -1377,6 +1383,8 @@ _git_grep ()
>                         --max-depth
>                         --count
>                         --and --or --not --all-match
> +                       --break --heading --show-function --function-context
> +                       --untracked --no-index
>                         "
>                 return
>                 ;;
> @@ -1576,7 +1584,7 @@ _git_mergetool ()
>                 return
>                 ;;
>         --*)
> -               __gitcomp "--tool="
> +               __gitcomp "--tool= --prompt --no-prompt"
>                 return
>                 ;;
>         esac
> @@ -2456,7 +2464,7 @@ _git_reset ()
>
>         case "$cur" in
>         --*)
> -               __gitcomp "--merge --mixed --hard --soft --patch"
> +               __gitcomp "--merge --mixed --hard --soft --patch --keep"
>                 return
>                 ;;
>         esac
> @@ -2472,7 +2480,10 @@ _git_revert ()
>         fi
>         case "$cur" in
>         --*)
> -               __gitcomp "--edit --mainline --no-edit --no-commit --signoff"
> +               __gitcomp "
> +                       --edit --mainline --no-edit --no-commit --signoff
> +                       --strategy= --strategy-option=
> +                       "
>                 return
>                 ;;
>         esac
> @@ -2483,7 +2494,7 @@ _git_rm ()
>  {
>         case "$cur" in
>         --*)
> -               __gitcomp "--cached --dry-run --ignore-unmatch --quiet"
> +               __gitcomp "--cached --dry-run --ignore-unmatch --quiet --force"
>                 return
>                 ;;
>         esac
> @@ -2500,7 +2511,7 @@ _git_shortlog ()
>                 __gitcomp "
>                         $__git_log_common_options
>                         $__git_log_shortlog_options
> -                       --numbered --summary
> +                       --numbered --summary --email
>                         "
>                 return
>                 ;;
> @@ -2778,8 +2789,8 @@ _git_tag ()
>         --*)
>                 __gitcomp "
>                         --list --delete --verify --annotate --message --file
> -                       --sign --cleanup --local-user --force --column --sort
> -                       --contains --points-at
> +                       --sign --cleanup --local-user --force --column --sort=
> +                       --contains --points-at --merged --no-merged --create-reflog
>                         "
>                 ;;
>         esac
> --
> 2.10.2
>

> On Fri, Jan 27, 2017 at 10:17 PM,  <cornelius.weig@tngtech.com> wrote:
>> From: Cornelius Weig <cornelius.weig@tngtech.com>
>>
>> Recognize several new long-options for bash completion in the following
>> commands:
> 
> Adding more long options that git commands learn along the way is
> always an improvement.  However, seeing "_several_ new long options"
> (or "some long options" in one of the other patches in the series)
> makes the reader wonder: are these the only new long options missing
> or are there more?  If there are more, why only these are added?  If
> there aren't any more missing long options left, then please say so,
> e.g. "Add all missing long options, except the potentially
> desctructive ones, for the following commands: ...."

> Hi Gabor,
>
>  thanks for taking a look at these commits.
>
> On 01/31/2017 11:17 PM, SZEDER Gábor wrote:
>> On Fri, Jan 27, 2017 at 10:17 PM,  <cornelius.weig@tngtech.com> wrote:
>>> From: Cornelius Weig <cornelius.weig@tngtech.com>
>>>
>>> Recognize several new long-options for bash completion in the following
>>> commands:
>>
>> Adding more long options that git commands learn along the way is
>> always an improvement.  However, seeing "_several_ new long options"
>> (or "some long options" in one of the other patches in the series)
>> makes the reader wonder: are these the only new long options missing
>> or are there more?  If there are more, why only these are added?  If
>> there aren't any more missing long options left, then please say so,
>> e.g. "Add all missing long options, except the potentially
>> desctructive ones, for the following commands: ...."
>
> Personally, I agree with you that
>> Adding more long options that git commands learn along the way is
>> always an improvement.
> However, people may start complaining that their terminal becomes too
> cluttered when doing a double-Tab. In my cover letter, I go to length
> about this. My assumption was that all options that are mentioned in the
> introduction of the command man-page should be important enough to have
> them in the completion list.

> I'll change my commit message accordingly.
>
>>>  - rm: --force
>>
>> '--force' is a potentially destructive option, too.
>
> Thanks for spotting this.
>
> Btw, I haven't found that non-destructive options should not be eligible
> for completion. To avoid confusion about this in the future, I suggest
> to also change the documentation:
>
> index 933bb6e..96f1c7f 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -13,7 +13,7 @@
>  #    *) git email aliases for git-send-email
>  #    *) tree paths within 'ref:path/to/file' expressions
>  #    *) file paths within current working directory and index
> -#    *) common --long-options
> +#    *) common non-destructive --long-options

>> Personally, I agree with you that
>>> Adding more long options that git commands learn along the way is
>>> always an improvement.
>> However, people may start complaining that their terminal becomes too
>> cluttered when doing a double-Tab. In my cover letter, I go to length
>> about this. My assumption was that all options that are mentioned in the
>> introduction of the command man-page should be important enough to have
>> them in the completion list.
> 
> But that doesn't mean that the ones not mentioned in the synopsis
> section are not worth completing.

>> Btw, I haven't found that non-destructive options should not be eligible
>> for completion. To avoid confusion about this in the future, I suggest
>> to also change the documentation:
>>
>> index 933bb6e..96f1c7f 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -13,7 +13,7 @@
>>  #    *) git email aliases for git-send-email
>>  #    *) tree paths within 'ref:path/to/file' expressions
>>  #    *) file paths within current working directory and index
>> -#    *) common --long-options
>> +#    *) common non-destructive --long-options
> 
> I don't mind such a change, but I don't think that list was ever meant
> to be comprehensive or decisive.  It is definitely not the former, as
> it's missing several things that the completion script does support.
> OTOH, it talks about .git/remotes, which has been considered legacy
> for quite some years (though it's right, because the completion script
> still supports it).

> Git-remote needs to complete remote names, its subcommands, and options
> thereof. In addition to the existing subcommand and remote name
> completion, do also complete the options
> 
>  - add: --track --master --fetch --tags --no-tags --mirror=

>  - set-url: --push --add --delete
>  - get-url: --push --all
>  - prune: --dry-run
> ---
>  contrib/completion/git-completion.bash | 36 +++++++++++++++++++++++++++-------
>  1 file changed, 29 insertions(+), 7 deletions(-)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index e76cbd7..0e09519 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2384,24 +2384,46 @@ _git_config ()
>  
>  _git_remote ()
>  {
> -	local subcommands="add rename remove set-head set-branches set-url show prune update"
> +	local subcommands="
> +		add rename remove set-head set-branches
> +		get-url set-url show prune update
> +		"
>  	local subcommand="$(__git_find_on_cmdline "$subcommands")"
>  	if [ -z "$subcommand" ]; then
> -		__gitcomp "$subcommands"
> +		case "$cur" in
> +		--*)
> +			__gitcomp "--verbose"
> +			;;
> +		*)
> +			__gitcomp "$subcommands"
> +			;;
> +		esac
>  		return
>  	fi
>  
> -	case "$subcommand" in
> -	rename|remove|set-url|show|prune)
> -		__gitcomp_nl "$(__git_remotes)"
> +	case "$subcommand,$cur" in
> +	add,--*)
> +		__gitcomp "--track --master --fetch --tags --no-tags --mirror="
>  		;;
> -	set-head|set-branches)
> +	add,*)
> +		;;
> +	set-head,*|set-branches,*)

>  		__gitcomp "$(__git_get_config_variables "remotes")"
>  		;;
> +	set-url,--*)
> +		__gitcomp "--push --add --delete"
> +		;;
> +	get-url,--*)
> +		__gitcomp "--push --all"
> +		;;
> +	prune,--*)
> +		__gitcomp "--dry-run"
> +		;;
>  	*)
> +		__gitcomp_nl "$(__git_remotes)"
>  		;;
>  	esac
>  }
> -- 
> 2.10.2

>>  		__git_complete_remote_or_refspec
>>  		;;
>> -	update)
>> +	update,*)
> 
> The 'update' subcommand has a '--prune' option.
> 

> ---
>  contrib/completion/git-completion.bash | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 8329f09..652c7e2 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -947,13 +947,17 @@ _git_add ()
>  	--*)
>  		__gitcomp "
>  			--interactive --refresh --patch --update --dry-run
> -			--ignore-errors --intent-to-add
> +			--ignore-errors --intent-to-add --force --edit --chmod=

>  			"
>  		return
>  	esac
>  
> -	# XXX should we check for --update and --all options ?
> -	__git_complete_index_file "--others --modified --directory --no-empty-directory"
> +	local complete_opt="--others --modified --directory --no-empty-directory"
> +	if test -n "$(__git_find_on_cmdline "-u --update")"
> +	then
> +		complete_opt="--modified"
> +	fi
> +	__git_complete_index_file "$complete_opt"
>  }
>  
>  _git_archive ()
> -- 
> 2.10.2