From: Cornelius Weig <redacted>
The cli interface for git has the greatest versatility of all git tools.
Its productivity depends on how easy it is to type commands and to remember
options. The command line completion helps two-fold by easing input and
displaying possible options.
Bash completion lacks support for several options and some useful commands.
Although the selection of recognized options is always opinionated (e.g. the
documentation for git-completion.bash says that 'common' long options are
recognized), I think that extending the cli completion will always increase the
productivity.
To that end, the following commits add completion support for several existing
options and subcommands. For every command all options that are mentioned in
the introduction of its man page should now be available for completion.
Cornelius Weig (7):
completion: teach options to submodule subcommands
completion: add subcommand completion for rerere
completion: improve bash completion for git-add
completion: teach ls-remote to complete options
completion: teach replace to complete options
completion: teach remote subcommands option completion
completion: recognize more long-options
contrib/completion/git-completion.bash | 132 +++++++++++++++++++++++++++------
1 file changed, 110 insertions(+), 22 deletions(-)
--
2.10.2
From: Cornelius Weig <redacted>
The subcommands of submodule have different long-options which command
line users need to type in. Therefore, teach bash completion to support
most subcommand options for submodule.
---
contrib/completion/git-completion.bash | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
From: Cornelius Weig <redacted>
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(+)
From: Cornelius Weig <redacted>
ls-remote needs to complete remote names and its own options. In
addition to the existing remote name completions, do also complete
the options --heads, --tags, --refs, and --get-url.
---
contrib/completion/git-completion.bash | 6 ++++++
1 file changed, 6 insertions(+)
From: Cornelius Weig <redacted>
Add some long-options for git-add and improve path completion when the
--update flag is given.
---
contrib/completion/git-completion.bash | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
From: Cornelius Weig <redacted>
Git-replace needs to complete references and its own options. In
addition to the existing references completions, do also complete the
options --edit --graft --format= --list --delete.
---
contrib/completion/git-completion.bash | 6 ++++++
1 file changed, 6 insertions(+)
From: Johannes Sixt <hidden> Date: 2017-01-24 07:16:05
If at all possible, please use your real email address as the From
address. It is pointless to hide behind a fake address because as Git
contributor you will have to reveal your identity anyway.
Please study item (5) "Sign your work" in
Documentation/SubmittingPatches and sign off your work.
I'm by no means a bash completion expert, but I have a comment on this
patch.
Am 22.01.2017 um 23:57 schrieb bitte.keine.werbung.einwerfen@googlemail.com:
Recognize several new long-options for bash completion in the following
commands:
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:
From: Cornelius Weig <hidden> Date: 2017-01-24 08:21:10
On 01/24/2017 08:15 AM, Johannes Sixt wrote:
If at all possible, please use your real email address as the From
address. It is pointless to hide behind a fake address because as Git
contributor you will have to reveal your identity anyway.
These are both real addresses, but for send-mail I would not want to use
my work account. I hope this is not a problem.
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.
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:
From: Cornelius Weig <redacted>
This revision addresses Johannes' concerns. Changes wrt v1:
- fixed the commit message: two of the "dangerous" options erroneously ended
up in the commit message. These options were already in the list of
auto-completable options.
- removed the possibly dangerous option '--unsafe-paths' from git-apply.
- added my sign-off
Patches 1-6 are not resent, because they have not changed (other than my added sign-off).
Also, I added further people to CC, because nobody actually has looked at the code yet.
Cornelius Weig (7):
completion: recognize more long-options
contrib/completion/git-completion.bash | 132 +++++++++++++++++++++++++++------
1 file changed, 110 insertions(+), 22 deletions(-)
--
2.10.2
From: SZEDER Gábor <hidden> Date: 2017-01-31 22:19:04
On Fri, Jan 27, 2017 at 10:17 PM, [off-list ref] wrote:
From: Cornelius Weig <redacted>
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: ...."
I almost started complaining that '--force' should be used with care,
but then realized that for 'git add' it only means adding ignored
files. So in this particular case '--force' is not destructive and we
can offer it among other long options. Good.
"
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
From: Cornelius Weig <hidden> Date: 2017-02-01 16:49:56
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, [off-list ref] wrote:
quoted
From: Cornelius Weig <redacted>
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.
quoted
- 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
@@ -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## To use these routines:#
I take it you have also looked at the code itself? Then I would gladly
mention you as reviewer in my sign-off.
From: SZEDER Gábor <hidden> Date: 2017-02-02 00:58:44
quoted hunk
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(+)
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.
From: SZEDER Gábor <hidden> Date: 2017-02-02 01:39:04
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=
Oh, '--track' and '--master' are not even in the manpage or in 'git
remote -h', I could only find them after looking at the source code...
Good eyes :)
From: SZEDER Gábor <hidden> Date: 2017-02-02 01:41:00
ls-remote needs to complete remote names and its own options.
And refnames, too.
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.
From: SZEDER Gábor <hidden> Date: 2017-02-02 02:00:14
On Wed, Feb 1, 2017 at 5:49 PM, Cornelius Weig
[off-list ref] wrote:
Hi Gabor,
thanks for taking a look at these commits.
On 01/31/2017 11:17 PM, SZEDER Gábor wrote:
quoted
On Fri, Jan 27, 2017 at 10:17 PM, [off-list ref] wrote:
quoted
From: Cornelius Weig <redacted>
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
quoted
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.
The list of options listed by the completion script for several of
these commands fits on a single line. The command with the most
options among these is 'git pull', and even its options don't fill
more than half of a 80x25 screen. I see no danger of people coming
complaining.
quoted hunk
I'll change my commit message accordingly.
quoted
quoted
- 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
@@ -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).
I take it you have also looked at the code itself? Then I would gladly
mention you as reviewer in my sign-off.
Yeah, most of the changes was rather straightforward, except the
completion of 'git remote's subcommands' options, but that looks
good, too.
Gábor
From: Cornelius Weig <hidden> Date: 2017-02-02 09:16:45
On 02/02/2017 01:57 AM, SZEDER Gábor wrote:
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.
Yes this is intentional. There is a number of plumbing commands that
have command completion, but are not listed in 'git <Tab><Tab>' (e.g.
ls-tree, ls-files, ls-remote, ...). Given that rerere will not be
frequently invoked, I would not add it to the porcelain commands.
From: Cornelius Weig <hidden> Date: 2017-02-02 09:41:08
On 02/02/2017 02:40 AM, SZEDER Gábor wrote:
quoted
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.
quoted
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.
My line of thought is the following:
--quiet: does not print anything and is therefore only useful for
scripting. Thus, there is no need to have it on the command line completion.
--exit-code: has no visible effect and is only useful for scripting.
--upload-pack: is really exotic. Nobody will ever use it without digging
deep in the manuals. Therefore, I think it's unnecessary to have the
option completable.
--symref: Should probably be added, thanks.
However, if you don't find my reasoning for omitting the three options
above conclusive, I have no problem including them.
From: Cornelius Weig <hidden> Date: 2017-02-02 10:40:12
On 02/02/2017 03:00 AM, SZEDER Gábor wrote:
quoted
Personally, I agree with you that
quoted
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.
Absolutely. What I meant is that at least the options from the synopsis
should be contained in the set of completable options.
quoted
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
@@ -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).
Then let's not do that change, because for some commands destructive
long-options have been in the list of completed options for quite a
while. Given that, the above change of the documentation, might stir up
more confusion than it settles.