git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* No log --no-decorate completion?
@ 2017-10-11 14:47 Max Rothman
  2017-10-11 18:09 ` Stefan Beller
  0 siblings, 1 reply; 13+ messages in thread
From: Max Rothman @ 2017-10-11 14:47 UTC (permalink / raw)
  To: git

I recently noticed that in the git-completion script, there's
completion for --decorate={full,yes,no} for git log and family, but
not for --no-decorate. Is that intentional? If not, I *think* I see
how it could be added.

Thanks,
Max

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: No log --no-decorate completion?
  2017-10-11 14:47 No log --no-decorate completion? Max Rothman
@ 2017-10-11 18:09 ` Stefan Beller
  2017-10-12 17:41   ` Max Rothman
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Beller @ 2017-10-11 18:09 UTC (permalink / raw)
  To: Max Rothman; +Cc: git

On Wed, Oct 11, 2017 at 7:47 AM, Max Rothman <max.r.rothman@gmail.com> wrote:
> I recently noticed that in the git-completion script, there's
> completion for --decorate={full,yes,no} for git log and family, but
> not for --no-decorate. Is that intentional? If not, I *think* I see
> how it could be added.
>
> Thanks,
> Max

Using git-blame, I found af4e9e8c87 (completion: update am, commit, and log,
2009-10-07) as well as af16bdaa3f (completion: fix and update 'git log
--decorate='
options, 2015-05-01), both of their commit messages do not discuss leaving out
--no-decorate intentionally.

If you give --no-<TAB> you'd get more than just the completion to --no-decorate,
but all the negated options, I would assume?

So maybe that is why no one added the negated options, yet?

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: No log --no-decorate completion?
  2017-10-11 18:09 ` Stefan Beller
@ 2017-10-12 17:41   ` Max Rothman
  2017-10-24 15:32     ` Max Rothman
       [not found]     ` <CAFA_24K99LkeJBKV7+a-m-m9PUZik49cOd40+cEn-6zCvGmMsQ@mail.gmail.com>
  0 siblings, 2 replies; 13+ messages in thread
From: Max Rothman @ 2017-10-12 17:41 UTC (permalink / raw)
  To: Stefan Beller; +Cc: git

To be fair, other --no* options complete, it's just --no-decorate,
--no-walk, --no-abbrev-commit, --no-expand-tabs, --no-patch,
--no-indent-heuristic, and --no-textconv that's missing.

For example:
$ git log --no<TAB><TAB>
--no-color         --no-max-parents   --no-min-parents   --no-prefix
     --not
--no-ext-diff      --no-merges        --no-notes         --no-renames
     --notes

Thanks,
Max

On Wed, Oct 11, 2017 at 2:09 PM, Stefan Beller <sbeller@google.com> wrote:
> On Wed, Oct 11, 2017 at 7:47 AM, Max Rothman <max.r.rothman@gmail.com> wrote:
>> I recently noticed that in the git-completion script, there's
>> completion for --decorate={full,yes,no} for git log and family, but
>> not for --no-decorate. Is that intentional? If not, I *think* I see
>> how it could be added.
>>
>> Thanks,
>> Max
>
> Using git-blame, I found af4e9e8c87 (completion: update am, commit, and log,
> 2009-10-07) as well as af16bdaa3f (completion: fix and update 'git log
> --decorate='
> options, 2015-05-01), both of their commit messages do not discuss leaving out
> --no-decorate intentionally.
>
> If you give --no-<TAB> you'd get more than just the completion to --no-decorate,
> but all the negated options, I would assume?
>
> So maybe that is why no one added the negated options, yet?
>
> Thanks,
> Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: No log --no-decorate completion?
  2017-10-12 17:41   ` Max Rothman
@ 2017-10-24 15:32     ` Max Rothman
       [not found]     ` <CAFA_24K99LkeJBKV7+a-m-m9PUZik49cOd40+cEn-6zCvGmMsQ@mail.gmail.com>
  1 sibling, 0 replies; 13+ messages in thread
From: Max Rothman @ 2017-10-24 15:32 UTC (permalink / raw)
  To: Stefan Beller; +Cc: git

Just re-discovered this in my inbox. So is this worth fixing? I could
(probably) figure out a patch.

Thanks,
Max

On Thu, Oct 12, 2017 at 1:41 PM, Max Rothman <max.r.rothman@gmail.com> wrote:
> To be fair, other --no* options complete, it's just --no-decorate,
> --no-walk, --no-abbrev-commit, --no-expand-tabs, --no-patch,
> --no-indent-heuristic, and --no-textconv that's missing.
>
> For example:
> $ git log --no<TAB><TAB>
> --no-color         --no-max-parents   --no-min-parents   --no-prefix
>      --not
> --no-ext-diff      --no-merges        --no-notes         --no-renames
>      --notes
>
> Thanks,
> Max
>
> On Wed, Oct 11, 2017 at 2:09 PM, Stefan Beller <sbeller@google.com> wrote:
>> On Wed, Oct 11, 2017 at 7:47 AM, Max Rothman <max.r.rothman@gmail.com> wrote:
>>> I recently noticed that in the git-completion script, there's
>>> completion for --decorate={full,yes,no} for git log and family, but
>>> not for --no-decorate. Is that intentional? If not, I *think* I see
>>> how it could be added.
>>>
>>> Thanks,
>>> Max
>>
>> Using git-blame, I found af4e9e8c87 (completion: update am, commit, and log,
>> 2009-10-07) as well as af16bdaa3f (completion: fix and update 'git log
>> --decorate='
>> options, 2015-05-01), both of their commit messages do not discuss leaving out
>> --no-decorate intentionally.
>>
>> If you give --no-<TAB> you'd get more than just the completion to --no-decorate,
>> but all the negated options, I would assume?
>>
>> So maybe that is why no one added the negated options, yet?
>>
>> Thanks,
>> Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: No log --no-decorate completion?
       [not found]     ` <CAFA_24K99LkeJBKV7+a-m-m9PUZik49cOd40+cEn-6zCvGmMsQ@mail.gmail.com>
@ 2017-10-24 15:32       ` Stefan Beller
  2017-11-02 20:25         ` Max Rothman
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Beller @ 2017-10-24 15:32 UTC (permalink / raw)
  To: Max Rothman; +Cc: git

On Tue, Oct 24, 2017 at 8:15 AM, Max Rothman <max.r.rothman@gmail.com> wrote:
> Just re-discovered this in my inbox. So is this worth fixing? I could
> (probably) figure out a patch.
>
> Thanks,
> Max
>

$ git log -- <TAB>
Display all 100 possibilities? (y or n)

I guess adding one more option is no big deal, so go for it!
We also have a couple --no-options already (as you said earlier),
which I think makes it even more viable.

Tangent:
I wonder if we can cascade the completion by common
prefixes, e.g. --no- or --ignore- occurs a couple of times,
such that we could only show these --no- once and only
if you try autocompleting thereafter you get all --no- options.

Thanks for reviving this thread!
Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: No log --no-decorate completion?
  2017-10-24 15:32       ` Stefan Beller
@ 2017-11-02 20:25         ` Max Rothman
  2017-11-02 21:19           ` Stefan Beller
  0 siblings, 1 reply; 13+ messages in thread
From: Max Rothman @ 2017-11-02 20:25 UTC (permalink / raw)
  To: Stefan Beller; +Cc: git

No problem! Let me know if I've done something wrong with this patch,
I'm new to git's contributor process.

completion: add missing completions for log, diff, show

* Add bash completion for the missing --no-* options on git log
* Add bash completion for --textconv and --indent-heuristic families to
  git diff and all commands that use diff's options
* Add bash completion for --no-abbrev-commit, --expand-tabs, and
  --no-expand-tabs to git show
---
 contrib/completion/git-completion.bash | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0e16f017a4144..252a6c8c0c80c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1412,6 +1412,8 @@ __git_diff_common_options="--stat --numstat
--shortstat --summary
                        --dirstat-by-file= --cumulative
                        --diff-algorithm=
                        --submodule --submodule=
+                       --indent-heuristic --no-indent-heuristic
+                       --textconv --no-textconv
 "

 _git_diff ()
@@ -1752,6 +1754,10 @@ _git_log ()
                __gitcomp "$__git_diff_submodule_formats" ""
"${cur##--submodule=}"
                return
                ;;
+       --no-walk=*)
+               __gitcomp "sorted unsorted" "" "${cur##--no-walk=}"
+               return
+               ;;
        --*)
                __gitcomp "
                        $__git_log_common_options
@@ -1759,16 +1765,19 @@ _git_log ()
                        $__git_log_gitk_options
                        --root --topo-order --date-order --reverse
                        --follow --full-diff
-                       --abbrev-commit --abbrev=
+                       --abbrev-commit --no-abbrev-commit --abbrev=
                        --relative-date --date=
                        --pretty= --format= --oneline
                        --show-signature
                        --cherry-mark
                        --cherry-pick
                        --graph
-                       --decorate --decorate=
+                       --decorate --decorate= --no-decorate
                        --walk-reflogs
+                       --no-walk --no-walk= --do-walk
                        --parents --children
+                       --expand-tabs --expand-tabs= --no-expand-tabs
+                       --patch
                        $merge
                        $__git_diff_common_options
                        --pickaxe-all --pickaxe-regex
@@ -2816,8 +2825,9 @@ _git_show ()
                return
                ;;
        --*)
-               __gitcomp "--pretty= --format= --abbrev-commit --oneline
-                       --show-signature
+               __gitcomp "--pretty= --format= --abbrev-commit
--no-abbrev-commit
+                       --oneline --show-signature --patch
+                       --expand-tabs --expand-tabs= --no-expand-tabs
                        $__git_diff_common_options
                        "
                return

On Tue, Oct 24, 2017 at 11:32 AM, Stefan Beller <sbeller@google.com> wrote:
> On Tue, Oct 24, 2017 at 8:15 AM, Max Rothman <max.r.rothman@gmail.com> wrote:
>> Just re-discovered this in my inbox. So is this worth fixing? I could
>> (probably) figure out a patch.
>>
>> Thanks,
>> Max
>>
>
> $ git log -- <TAB>
> Display all 100 possibilities? (y or n)
>
> I guess adding one more option is no big deal, so go for it!
> We also have a couple --no-options already (as you said earlier),
> which I think makes it even more viable.
>
> Tangent:
> I wonder if we can cascade the completion by common
> prefixes, e.g. --no- or --ignore- occurs a couple of times,
> such that we could only show these --no- once and only
> if you try autocompleting thereafter you get all --no- options.
>
> Thanks for reviving this thread!
> Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: No log --no-decorate completion?
  2017-11-02 20:25         ` Max Rothman
@ 2017-11-02 21:19           ` Stefan Beller
  2017-11-07 20:31             ` Max Rothman
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Beller @ 2017-11-02 21:19 UTC (permalink / raw)
  To: Max Rothman; +Cc: git

On Thu, Nov 2, 2017 at 1:25 PM, Max Rothman <max.r.rothman@gmail.com> wrote:
> No problem! Let me know if I've done something wrong with this patch,
> I'm new to git's contributor process.

Thanks for coming up with a patch!
Yeah, the contribution process has some initial road blocks;
I'll point them out below.

> completion: add missing completions for log, diff, show

I would think this is a good commit subject as it describes
the changes made superficially

> * Add bash completion for the missing --no-* options on git log
> * Add bash completion for --textconv and --indent-heuristic families to
>   git diff and all commands that use diff's options
> * Add bash completion for --no-abbrev-commit, --expand-tabs, and
>   --no-expand-tabs to git show

This describes what happens in this patch, but not why, which helps
future readers of commit message more than the "what".
I'm also just guessing but maybe:

    A user might have configured a repo to show diffs in a certain way,
    add the --no-* options to the autocompletion to override it easier
    from the command line.
    New in this patch is autocompletion for --textconv as well as abbreviation
    options as that needs to be flipped all the time in <example workflow>.

I wonder if we really want to expose indent-heuristic,
I guess by not having it experimental any more it makes sense to do so.
c.f. https://public-inbox.org/git/20171029151228.607834-1-cmn@dwim.me/

At the end of a commit message, the Git project requires a sign off.
(See section (5) in Documentation/SubmittingPatches;
tl;dr: add Signed-off-by: NAME <EMAIL> if you can agree to
https://developercertificate.org/)

> ---
>  contrib/completion/git-completion.bash | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 0e16f017a4144..252a6c8c0c80c 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1412,6 +1412,8 @@ __git_diff_common_options="--stat --numstat
> --shortstat --summary
>                         --dirstat-by-file= --cumulative
>                         --diff-algorithm=
>                         --submodule --submodule=
> +                       --indent-heuristic --no-indent-heuristic
> +                       --textconv --no-textconv
>  "
>
>  _git_diff ()
> @@ -1752,6 +1754,10 @@ _git_log ()
>                 __gitcomp "$__git_diff_submodule_formats" ""
> "${cur##--submodule=}"
>                 return
>                 ;;
> +       --no-walk=*)
> +               __gitcomp "sorted unsorted" "" "${cur##--no-walk=}"
> +               return
> +               ;;
>         --*)
>                 __gitcomp "
>                         $__git_log_common_options
> @@ -1759,16 +1765,19 @@ _git_log ()
>                         $__git_log_gitk_options
>                         --root --topo-order --date-order --reverse
>                         --follow --full-diff
> -                       --abbrev-commit --abbrev=
> +                       --abbrev-commit --no-abbrev-commit --abbrev=
>                         --relative-date --date=
>                         --pretty= --format= --oneline
>                         --show-signature
>                         --cherry-mark
>                         --cherry-pick
>                         --graph
> -                       --decorate --decorate=
> +                       --decorate --decorate= --no-decorate
>                         --walk-reflogs
> +                       --no-walk --no-walk= --do-walk
>                         --parents --children
> +                       --expand-tabs --expand-tabs= --no-expand-tabs
> +                       --patch
>                         $merge
>                         $__git_diff_common_options
>                         --pickaxe-all --pickaxe-regex
> @@ -2816,8 +2825,9 @@ _git_show ()
>                 return
>                 ;;
>         --*)
> -               __gitcomp "--pretty= --format= --abbrev-commit --oneline
> -                       --show-signature
> +               __gitcomp "--pretty= --format= --abbrev-commit
> --no-abbrev-commit
> +                       --oneline --show-signature --patch
> +                       --expand-tabs --expand-tabs= --no-expand-tabs
>                         $__git_diff_common_options
>                         "
>                 return
>

The patch looks good, but doesn't apply because the email contains
white spaces instead of tabs. Maybe try https://submitgit.herokuapp.com/
(or fix/change your email client to send a patch; the gmail web interface
doesn't work. I personally got 'git send-email' up and running;
The Documentation/SubmittingPatches has a section on email clients, too)

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: No log --no-decorate completion?
  2017-11-02 21:19           ` Stefan Beller
@ 2017-11-07 20:31             ` Max Rothman
  2017-11-07 20:48               ` Stefan Beller
  0 siblings, 1 reply; 13+ messages in thread
From: Max Rothman @ 2017-11-07 20:31 UTC (permalink / raw)
  To: Stefan Beller; +Cc: git

Thanks for the feedback!

>> * Add bash completion for the missing --no-* options on git log
>> * Add bash completion for --textconv and --indent-heuristic families to
>>   git diff and all commands that use diff's options
>> * Add bash completion for --no-abbrev-commit, --expand-tabs, and
>>   --no-expand-tabs to git show
>
> This describes what happens in this patch, but not why, which helps
> future readers of commit message more than the "what".

How about:

> Teach git-log tab completion about the --no-* options for ease of use
> at the command line.
>
> Similarly, teach git-show tab completion about the --no-abbrev-commit,
> --expand-tabs, and --no-expand-tabs options.
>
> Also, teach git-diff (and all commands that use its options) tab
> completion about the --textconv and --indent-heuristic families of
> options. --indent-heuristic is no longer experimental, so there's no
> reason it should be left out of tab completion any more, and textconv
> seems to have simply been missed.


> At the end of a commit message, the Git project requires a sign off.
> (See section (5) in Documentation/SubmittingPatches;
> tl;dr: add Signed-off-by: NAME <EMAIL> if you can agree to
> https://developercertificate.org/)

So the sign-off should include my name and email? I thought it was
supposed to be the person who approved the patch, but I must've gotten
confused.

> The patch looks good, but doesn't apply because the email contains
> white spaces instead of tabs. Maybe try https://submitgit.herokuapp.com/
> (or fix/change your email client to send a patch; the gmail web interface
> doesn't work. I personally got 'git send-email' up and running;
> The Documentation/SubmittingPatches has a section on email clients, too)

Yeah, I was using the gmail interface. I'll give the heroku app a go.
It has an option for sending a message in reply to another, and I
assume I should send it in reply to this thread. Do you know how to
tell what the appropriate ID to use is? Looking through the raw email,
I see several, so it's not obvious to me which to use.

Thanks,
Max

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: No log --no-decorate completion?
  2017-11-07 20:31             ` Max Rothman
@ 2017-11-07 20:48               ` Stefan Beller
  2017-11-07 21:22                 ` [PATCH] completion: add missing completions for log, diff, show Max Rothman
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Beller @ 2017-11-07 20:48 UTC (permalink / raw)
  To: Max Rothman; +Cc: git

On Tue, Nov 7, 2017 at 12:31 PM, Max Rothman <max.r.rothman@gmail.com> wrote:
> Thanks for the feedback!
>
>>> * Add bash completion for the missing --no-* options on git log
>>> * Add bash completion for --textconv and --indent-heuristic families to
>>>   git diff and all commands that use diff's options
>>> * Add bash completion for --no-abbrev-commit, --expand-tabs, and
>>>   --no-expand-tabs to git show
>>
>> This describes what happens in this patch, but not why, which helps
>> future readers of commit message more than the "what".
>
> How about:
>
>> Teach git-log tab completion about the --no-* options for ease of use
>> at the command line.
>>
>> Similarly, teach git-show tab completion about the --no-abbrev-commit,
>> --expand-tabs, and --no-expand-tabs options.
>>
>> Also, teach git-diff (and all commands that use its options) tab
>> completion about the --textconv and --indent-heuristic families of
>> options. --indent-heuristic is no longer experimental, so there's no
>> reason it should be left out of tab completion any more, and textconv
>> seems to have simply been missed.

Sounds good to me.


>> At the end of a commit message, the Git project requires a sign off.
>> (See section (5) in Documentation/SubmittingPatches;
>> tl;dr: add Signed-off-by: NAME <EMAIL> if you can agree to
>> https://developercertificate.org/)
>
> So the sign-off should include my name and email? I thought it was
> supposed to be the person who approved the patch, but I must've gotten
> confused.

Anyone touching the patch needs to sign off on it. So when you write it,
you sign off (thereby certifying that you are legally allowed to write
the patch.
For example you may be employed and the work contract requires you to
not work on side projects, or the intellectual property belongs to the employer
or such).

Hypothetically you could send it to Git-for-Windows which happens to
be a fork of git. The maintainer of GfW would gladly accept your patch,
(and also sign it off, thereby certifying he can touch it legally).
Thereafter someone such as a regular contributor from the git project
could spot the difference in GfW and git, and they would want to bring it
to "the real git", so they would make a patch out of the commit in GfW.
Additionally to the 2 sign offs, this contributor would also need to sign
off on the patch, saying it is legal what they do. And then that patch could
be picked up by the maintainer for the regular git. After that journey the
patch would have 4 sign offs, indicating the way of travel, i.e. how
it reached git finally.

An example of a longer sign off chain is  89dd32aedc
(check-ref-format doc: --branch validates and expands <branch>, 2017-10-17)
and apparently Jeff helped Junio to author a patch; Jonathan took that
patch and changed a thing, only to send it back to Junio, who then applied
it to git.


>> The patch looks good, but doesn't apply because the email contains
>> white spaces instead of tabs. Maybe try https://submitgit.herokuapp.com/
>> (or fix/change your email client to send a patch; the gmail web interface
>> doesn't work. I personally got 'git send-email' up and running;
>> The Documentation/SubmittingPatches has a section on email clients, too)
>
> Yeah, I was using the gmail interface. I'll give the heroku app a go.
> It has an option for sending a message in reply to another, and I
> assume I should send it in reply to this thread. Do you know how to
> tell what the appropriate ID to use is? Looking through the raw email,
> I see several, so it's not obvious to me which to use.

In gmail, there is a "show original" in the menu near reply, which will
show Message ID<CAFA_24L5nTUhO=PbMB9SdnCB1Lj+5rmOHmMJwkuLGWgy-ooxBA@mail.gmail.com>
for the email that I am responding to.

Another way to explore the message ids is public-inbox, as that uses
the message ids as keys, i.e.

  https://public-inbox.org/git/CAFA_24L5nTUhO=PbMB9SdnCB1Lj+5rmOHmMJwkuLGWgy-ooxBA@mail.gmail.com

is your email there.

Thanks,
Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH] completion: add missing completions for log, diff, show
  2017-11-07 20:48               ` Stefan Beller
@ 2017-11-07 21:22                 ` Max Rothman
  2017-11-08  2:33                   ` Junio C Hamano
  0 siblings, 1 reply; 13+ messages in thread
From: Max Rothman @ 2017-11-07 21:22 UTC (permalink / raw)
  To: git

From: Max Rothman <max-rothman@pluralsight.com>

Teach git-log tab completion about the --no-* options for ease of use
at the command line.

Similarly, teach git-show tab completion about the --no-abbrev-commit,
--expand-tabs, and --no-expand-tabs options.

Also, teach git-diff (and all commands that use its options) tab
completion about the --textconv and --indent-heuristic families of
options. --indent-heuristic is no longer experimental, so there's no
reason it should be left out of tab completion any more, and textconv
seems to have simply been missed.
---
 contrib/completion/git-completion.bash | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0e16f017a4144..252a6c8c0c80c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1412,6 +1412,8 @@ __git_diff_common_options="--stat --numstat --shortstat --summary
 			--dirstat-by-file= --cumulative
 			--diff-algorithm=
 			--submodule --submodule=
+			--indent-heuristic --no-indent-heuristic
+			--textconv --no-textconv
 "
 
 _git_diff ()
@@ -1752,6 +1754,10 @@ _git_log ()
 		__gitcomp "$__git_diff_submodule_formats" "" "${cur##--submodule=}"
 		return
 		;;
+	--no-walk=*)
+		__gitcomp "sorted unsorted" "" "${cur##--no-walk=}"
+		return
+		;;
 	--*)
 		__gitcomp "
 			$__git_log_common_options
@@ -1759,16 +1765,19 @@ _git_log ()
 			$__git_log_gitk_options
 			--root --topo-order --date-order --reverse
 			--follow --full-diff
-			--abbrev-commit --abbrev=
+			--abbrev-commit --no-abbrev-commit --abbrev=
 			--relative-date --date=
 			--pretty= --format= --oneline
 			--show-signature
 			--cherry-mark
 			--cherry-pick
 			--graph
-			--decorate --decorate=
+			--decorate --decorate= --no-decorate
 			--walk-reflogs
+			--no-walk --no-walk= --do-walk
 			--parents --children
+			--expand-tabs --expand-tabs= --no-expand-tabs
+			--patch
 			$merge
 			$__git_diff_common_options
 			--pickaxe-all --pickaxe-regex
@@ -2816,8 +2825,9 @@ _git_show ()
 		return
 		;;
 	--*)
-		__gitcomp "--pretty= --format= --abbrev-commit --oneline
-			--show-signature
+		__gitcomp "--pretty= --format= --abbrev-commit --no-abbrev-commit
+			--oneline --show-signature --patch
+			--expand-tabs --expand-tabs= --no-expand-tabs
 			$__git_diff_common_options
 			"
 		return

--
https://github.com/git/git/pull/426

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] completion: add missing completions for log, diff, show
  2017-11-07 21:22                 ` [PATCH] completion: add missing completions for log, diff, show Max Rothman
@ 2017-11-08  2:33                   ` Junio C Hamano
  2017-11-08  3:30                     ` Max Rothman
  0 siblings, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2017-11-08  2:33 UTC (permalink / raw)
  To: Max Rothman; +Cc: git

Max Rothman <max.r.rothman@gmail.com> writes:

> From: Max Rothman <max-rothman@pluralsight.com>

Thanks.

>
> Teach git-log tab completion about the --no-* options for ease of use
> at the command line.
>
> Similarly, teach git-show tab completion about the --no-abbrev-commit,
> --expand-tabs, and --no-expand-tabs options.
>
> Also, teach git-diff (and all commands that use its options) tab
> completion about the --textconv and --indent-heuristic families of
> options. --indent-heuristic is no longer experimental, so there's no
> reason it should be left out of tab completion any more, and textconv
> seems to have simply been missed.

A couple of things that I found questionable in the above
descriptions are:

 * We do not write git subcommand names like git-foo these days, as
   nobody type them like so.

 * The patch is not teaching git-foo about completing its options.
   It teaches the bash completion about options for git subcommands
   it did not know about.

So perhaps

	The bash completion script knows some options to the "git
	log" only in the positive form (e.g. "--abbrev-commit") but
	not in their negated form (e.g. "--no-abbrev-commit").  Add
	them.

and similar?

> ---

Missed sign-off?

> @@ -1759,16 +1765,19 @@ _git_log ()
> ...
> -			--decorate --decorate=
> +			--decorate --decorate= --no-decorate
> ...
> @@ -2816,8 +2825,9 @@ _git_show ()
>  		return
>  		;;
>  	--*)
> -		__gitcomp "--pretty= --format= --abbrev-commit --oneline
> -			--show-signature
> +		__gitcomp "--pretty= --format= --abbrev-commit --no-abbrev-commit
> +			--oneline --show-signature --patch
> +			--expand-tabs --expand-tabs= --no-expand-tabs
>  			$__git_diff_common_options
>  			"
>  		return

It's a bit sad that the completion support does not know that "git
show" belongs to the "git log" family of commands.  A consequence of
this is that "git show --no-decorate" is perfectly acceptable but
needs to be taught separately to _git_show if we wanted to.

Perhaps some selected options _git_log understands may need to be
split $__git_log_ui_common_options [*1*], like we do for "git diff"
family with $__git_diff_common_options, and shared between _git_log
and _git_show.

I am mentioning this primarily as #leftoverbits and I do not want to
see such a change mixed into this patch, as it is totally outside
the scope of it.  It is (if you are inclined to do so) OK to make
this into two patch series, with 1/2 doing such a refactoring
without changing any externally visible functionality (i.e. just
move the ones _git_show knows about to $__git_log_ui_common_options,
and have _git_show and _git_log use it), and 2/2 adding more options
to that list to achieve what you wanted to do with this patch, though.

Thanks.


[Footnote]

*1* $__git_log_common_options is taken and it is about options
    common to "log/shortlog/gitk" but contains some that are not
    relevant to "git show", and that is why I am suggesting a
    separate and new variable.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] completion: add missing completions for log, diff, show
  2017-11-08  2:33                   ` Junio C Hamano
@ 2017-11-08  3:30                     ` Max Rothman
  2017-11-08  4:06                       ` Junio C Hamano
  0 siblings, 1 reply; 13+ messages in thread
From: Max Rothman @ 2017-11-08  3:30 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

>> Teach git-log tab completion about the --no-* options for ease of use
>> at the command line.
>>
>> Similarly, teach git-show tab completion about the --no-abbrev-commit,
>> --expand-tabs, and --no-expand-tabs options.
>>
>> Also, teach git-diff (and all commands that use its options) tab
>> completion about the --textconv and --indent-heuristic families of
>> options. --indent-heuristic is no longer experimental, so there's no
>> reason it should be left out of tab completion any more, and textconv
>> seems to have simply been missed.
>
> A couple of things that I found questionable in the above
> descriptions are:
>
>  * We do not write git subcommand names like git-foo these days, as
>    nobody type them like so.

My bad, that's still how they're named when using manpages, so that's
what my muscle memory did.

>
>  * The patch is not teaching git-foo about completing its options.
>    It teaches the bash completion about options for git subcommands
>    it did not know about.
>
> So perhaps
>
>         The bash completion script knows some options to the "git
>         log" only in the positive form (e.g. "--abbrev-commit") but
>         not in their negated form (e.g. "--no-abbrev-commit").  Add
>         them.
>
> and similar?

How about this:

The bash completion script knows some options to "git log" and
"git show" only in the positive form, (e.g. "--abbrev-commit"), but not
in their negative form (e.g. "--no-abbrev-commit"). Adds them.

Also, the bash completion script is missing some other options to
"git diff", and "git show" (and thus, all other commands that take
"git diff"'s options). Adds them. Of note, since "--indent-heuristic" is
no longer experimental, adds that too.

>
>> ---
>
> Missed sign-off?

Whoops, there doesn't seem to be a way to add that separately from the
commit message in the submitGit interface. I'll try adding it, but
gmail might turn all the tabs into spaces, so if it does, I'll try to
figure out how to resubmit.

>
>> @@ -1759,16 +1765,19 @@ _git_log ()
>> ...
>> -                     --decorate --decorate=
>> +                     --decorate --decorate= --no-decorate
>> ...
>> @@ -2816,8 +2825,9 @@ _git_show ()
>>               return
>>               ;;
>>       --*)
>> -             __gitcomp "--pretty= --format= --abbrev-commit --oneline
>> -                     --show-signature
>> +             __gitcomp "--pretty= --format= --abbrev-commit --no-abbrev-commit
>> +                     --oneline --show-signature --patch
>> +                     --expand-tabs --expand-tabs= --no-expand-tabs
>>                       $__git_diff_common_options
>>                       "
>>               return
>
> It's a bit sad that the completion support does not know that "git
> show" belongs to the "git log" family of commands.  A consequence of
> this is that "git show --no-decorate" is perfectly acceptable but
> needs to be taught separately to _git_show if we wanted to.
>
> Perhaps some selected options _git_log understands may need to be
> split $__git_log_ui_common_options [*1*], like we do for "git diff"
> family with $__git_diff_common_options, and shared between _git_log
> and _git_show.
>
> I am mentioning this primarily as #leftoverbits and I do not want to
> see such a change mixed into this patch, as it is totally outside
> the scope of it.  It is (if you are inclined to do so) OK to make
> this into two patch series, with 1/2 doing such a refactoring
> without changing any externally visible functionality (i.e. just
> move the ones _git_show knows about to $__git_log_ui_common_options,
> and have _git_show and _git_log use it), and 2/2 adding more options
> to that list to achieve what you wanted to do with this patch, though.

I think I'll stick with this patch for now (it's my first!), but I
might come around and do refactoring in a second pass.

Thanks,
Max

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] completion: add missing completions for log, diff, show
  2017-11-08  3:30                     ` Max Rothman
@ 2017-11-08  4:06                       ` Junio C Hamano
  0 siblings, 0 replies; 13+ messages in thread
From: Junio C Hamano @ 2017-11-08  4:06 UTC (permalink / raw)
  To: Max Rothman; +Cc: git

Max Rothman <max.r.rothman@gmail.com> writes:

> How about this:
>
> The bash completion script knows some options to "git log" and
> "git show" only in the positive form, (e.g. "--abbrev-commit"), but not
> in their negative form (e.g. "--no-abbrev-commit"). Adds them.

s/Adds them/Add them/; we speak as if we are giving an order to 
the codebase to "become like so" (or to the patch monkey to "make
the code so").

> Also, the bash completion script is missing some other options to
> "git diff", and "git show" (and thus, all other commands that take
> "git diff"'s options). Adds them. Of note, since "--indent-heuristic" is
> no longer experimental, adds that too.

Likewise for the two "adds".

>>> ---
>>
>> Missed sign-off?
>
> Whoops, there doesn't seem to be a way to add that separately from the
> commit message in the submitGit interface. I'll try adding it, but
> gmail might turn all the tabs into spaces, so if it does, I'll try to
> figure out how to resubmit.

I would imagine that the cleanest way is to "commit --amend" and
have submitGit see that updated/corrected copy.

Thanks.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, back to index

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-11 14:47 No log --no-decorate completion? Max Rothman
2017-10-11 18:09 ` Stefan Beller
2017-10-12 17:41   ` Max Rothman
2017-10-24 15:32     ` Max Rothman
     [not found]     ` <CAFA_24K99LkeJBKV7+a-m-m9PUZik49cOd40+cEn-6zCvGmMsQ@mail.gmail.com>
2017-10-24 15:32       ` Stefan Beller
2017-11-02 20:25         ` Max Rothman
2017-11-02 21:19           ` Stefan Beller
2017-11-07 20:31             ` Max Rothman
2017-11-07 20:48               ` Stefan Beller
2017-11-07 21:22                 ` [PATCH] completion: add missing completions for log, diff, show Max Rothman
2017-11-08  2:33                   ` Junio C Hamano
2017-11-08  3:30                     ` Max Rothman
2017-11-08  4:06                       ` Junio C Hamano

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox