Some sub-commands can't be completed by TAB key.

On Ubuntu 20.04.3 LTS, I use the following git version installed from its apt repository:

$ git --version git version 2.25.1

I find that there are some  sub-commands can't be completed by TAB key:

$ git <TAB>
add               cherry-pick       fetch             latexdiff
 pull              restore           status
am                citool            format-patch      log
 push              revert            submodule
apply             clean             fsck              merge
 range-diff        rm                switch
archive           clone             gc                mergetool
 rebase            send-email        tag
bisect            commit            gitk              mv
 reflog            shortlog          whatchanged
blame             config            grep              nbdiffdriver
 remote            show              worktree
branch            deborig           gui               nbdifftool
 repack            show-branch
bundle            describe          help              nbmergedriver
 replace           sparse-checkout
checkout          diff              init              nbmergetool
 request-pull      stage
cherry            difftool          instaweb          notes
 reset             stash

As you can see, there are some sub-commands which are not listed in the above list, for example, the following ones:

$ git ls-remote $ git ls-files

Any hints for this problem?

Regards

Am 22.01.22 um 09:42 schrieb Hongyi Zhao:

Tab completion is only available for user-facing sub-commands ("porcelain"), but not for sub-commands intended for scripting ("plumbing"). The intent is to make tab completion more efficient during day-to-day work on the command line. For example,

   $ git l<TAB>

arrives at

   $ git log <cursor here>

instead of

   log     ls-files     ls-remote     ls-tree
   $ git l<cursor here>

-- Hannes

On Sat, Jan 22, 2022 at 10:47 PM Johannes Sixt <j6t@kdbg.org> wrote:

But there are so many git sub-commands, so if the plumbing feature is supported, it will facilitate user to check the availability of some sub-commands.

I see the following:

$ git l<TAB> latexdiff log

Hi Hongyi,

Le 2022-01-22 à 19:38, Hongyi Zhao a écrit :

If what you want to do is "check the availability" of some sub-command, you can simply do 'git <subcommand> -h', for example, and see if Git recognizes the subcommand.

If you mean discovering Git commands, you can use 'git help -a', which will list all commands, including pluming commands.

If you want to customize the Bash completion so that some select plumbing commands do appear in the tab completion, you can use the config 'completion.commands' [1]. Setting it to "ls-files ls-remote ls-tree" would then give you your desired output below.

This would mean you have a 'git-latexdiff' command somewhere in your PATH.

Hope that helps,

Philippe.

[1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-completioncommands

Philippe Blain <levraiphilippeblain@gmail.com> writes:

True. On Debian-based systems, the texlive-extra-utils package has /usr/bin/git-latexdiff and that is likely where it came from.

It is also worth noting that completion will also include whatever alias. I get "lg" in the mix because I have

        [alias]
                lg = "log --oneline"

in my $HOME/.gitconfig, for example.

On Mon, Jan 24, 2022 at 3:51 AM Junio C Hamano <gitster@pobox.com> wrote:

Mine comes from TexLive:

$ which git-latexdiff /opt/texlive/2021/bin/x86_64-linux/git-latexdiff

Good example. Got it.

HZ

That sounds like something that should be hidden, no? Like, all aliases are left unmentioned?

João Victor Bonfim <JoaoVictorBonfim+Git-Mail-List@protonmail.com> writes:

Unlike the plumbing commands that are meant to be used in writing scripts and not typed in interactive sessions, and more like Porcelain commands that are meant to be used by human end-users in their interactive sessions by getting typed from the keyboard, an aliase is often (and certainly my "lg" is) defined in order to give a short-and-sweet typesaver to a command with common initial options that the user finds useful in their interactive sessions.

I am curious to find out what makes you think it is a good idea to omit them from completion.

Add a GIT_COMPLETION_SHOW_ALL_COMMANDS=1 configuration setting to go with the existing GIT_COMPLETION_SHOW_ALL=1 added in c099f579b98 (completion: add GIT_COMPLETION_SHOW_ALL env var, 2020-08-19).

This will include plumbing commands such as "cat-file" in "git <TAB>" and "git c<TAB>" completion. Without/with this I have 134 and 243 completion with git <TAB>, respectively.

It was already possible to do this by tweaking GIT_COMPLETION_SHOW_ALL_COMMANDS from the outside, that testing variable was added in 84a97131065 (completion: let git provide the completable command list, 2018-05-20). Doing this before loading git-completion.bash worked:

    export GIT_TESTING_PORCELAIN_COMMAND_LIST="$(git --list-cmds=builtins,main,list-mainporcelain,others,nohelpers,alias,list-complete,config)"

But such testing variables are not meant to be used from the outside, and we make no guarantees that those internal won't change. So let's expose this as a dedicated configuration knob.

1. https://lore.kernel.org/git/CAGP6POJ9gwp+t-eP3TPkivBLLbNb2+qj=61Mehcj=1BgrVOSLA@mail.gmail.com/

Reported-by: Hongyi Zhao <hongyi.zhao@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---

n Sat, Jan 22 2022, Hongyi Zhao wrote:

Others have explained why this happens, but as noted above an easy but undocumented workaround for this that I use, because I'd like e.g. "cat-file" to show up in this completion. In your ~/.bashrc or equivalent do something like this before it loads git-completion.bash:

    export GIT_TESTING_PORCELAIN_COMMAND_LIST="$(git --list-cmds=builtins,main,others,alias)"

But it would be even nicer to turn that into a first-class feature, this patch does so. With this you can just do:

    export GIT_COMPLETION_SHOW_ALL_COMMANDS=1

 contrib/completion/git-completion.bash | 13 ++++++++++++-
 t/t9902-completion.sh                  | 27 ++++++++++++++++++++++++++
 2 files changed, 39 insertions(+), 1 deletion(-)

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

OK.  This makes sense in the sense that more choice is better.

Perhaps there is a typo that ruined whole the paragraph. We are adding that variable with this patch, so by definition, it did not exist before, which means we cannot "tweak" it because it did not exist.

Usually we frown upon inserting a new thing to the middle of a list of things that has no inherent order. In this case, I think this is OK, as the existing "all" (below) is about completing options, while the new one is about completing subcommands, and the latter is at a higher conceptual level than the former.

It is sad that there is no "plumbing" class (assuming the goal is "we by default exclude plumbing, so add that to the list"), or just "everything under the sun" class. If there were a plumbing command that is not implemented as a built-in, adding buitlins to list_cmds will not show the command, will it? Also, because nohelpers is not removed from list_cmds, whatever command that were removed from exclude_helpers_from_list() will be hidden.

It looks as though help.c needs a new list_all_cmds() that can be called from git.c::list_cmds() when "all" is asked for, and dumps everything from command_list[] plus whatever load_command_list() loads.

Having said all that, assuming that including "builtins" is a good enough approximation (which I do not have no opinion on), the implementation looks good to me.

As we've done dot-sourcing of the file at the beginning of the script already, dot-sourcing the same thing again would only overwrite what was done before, without clearing the deck. Which may not hurt for the purpose of _this_ test _right_ _now_q.

But as this is not done inside a subshell, whetever we dot-source here will persist til the end of the script. Which may be more problematic as it will affect the tests that come (and new tests that will be added) after this point.

The same comment applies to the other new test added immediately after this one.

Other than that, looks sensible to me.

Thanks.

This series adds an opt-in configuration to make "git <TAB>" complete the likes of "cat-file" (plumbing), in addition to the existing completion for the likes of "status" (porcelain).

This v2 addresses feedback from Junio on the v1, I also added a preceding patch to change the re-sourcing of git-completion.bash in some existing tests to use a subshell, which is a pattern I'd buggily copied in the v1.

Ævar Arnfjörð Bjarmason (2):
  completion tests: re-source git-completion.bash in a subshell
  completion: add a GIT_COMPLETION_SHOW_ALL_COMMANDS

 contrib/completion/git-completion.bash | 13 ++++-
 t/t9902-completion.sh                  | 81 +++++++++++++++++++-------
 2 files changed, 72 insertions(+), 22 deletions(-)

Range-diff against v1:
-:  ----------- > 1:  cf09546e079 completion tests: re-source git-completion.bash in a subshell
1:  5f18305ca08 ! 2:  2e2e3569e02 completion: add a GIT_COMPLETION_SHOW_ALL_COMMANDS
    @@ Commit message
         completion with git <TAB>, respectively.
     
         It was already possible to do this by tweaking
    -    GIT_COMPLETION_SHOW_ALL_COMMANDS from the outside, that testing
    +    GIT_TESTING_PORCELAIN_COMMAND_LIST= from the outside, that testing
         variable was added in 84a97131065 (completion: let git provide the
         completable command list, 2018-05-20). Doing this before loading
         git-completion.bash worked:
    @@ Commit message
         and we make no guarantees that those internal won't change. So let's
         expose this as a dedicated configuration knob.
     
    +    It would be better to teach --list-cmds=* a new category which would
    +    include all of these groups, but that's a larger change that we can
    +    leave for some other time.
    +
         1. https://lore.kernel.org/git/CAGP6POJ9gwp+t-eP3TPkivBLLbNb2+qj=61Mehcj=1BgrVOSLA@mail.gmail.com/
     
         Reported-by: Hongyi Zhao <hongyi.zhao@gmail.com>
    @@ contrib/completion/git-completion.bash: __git_main ()
     
      ## t/t9902-completion.sh ##
     @@ t/t9902-completion.sh: test_expect_success 'option aliases are shown with GIT_COMPLETION_SHOW_ALL' '
    - 	EOF
    + 	)
      '
      
     +test_expect_success 'plumbing commands are excluded without GIT_COMPLETION_SHOW_ALL_COMMANDS' '
    -+	. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
    -+	sane_unset GIT_TESTING_PORCELAIN_COMMAND_LIST &&
    ++	(
    ++		. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
    ++		sane_unset GIT_TESTING_PORCELAIN_COMMAND_LIST &&
     +
    -+	# Just mainporcelain, not plumbing commands
    -+	run_completion "git c" &&
    -+	grep checkout out &&
    -+	! grep cat-file out
    ++		# Just mainporcelain, not plumbing commands
    ++		run_completion "git c" &&
    ++		grep checkout out &&
    ++		! grep cat-file out
    ++	)
     +'
     +
     +test_expect_success 'all commands are shown with GIT_COMPLETION_SHOW_ALL_COMMANDS (also main non-builtin)' '
    -+	. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
    -+	GIT_COMPLETION_SHOW_ALL_COMMANDS=1 &&
    -+	export GIT_COMPLETION_SHOW_ALL_COMMANDS &&
    -+	sane_unset GIT_TESTING_PORCELAIN_COMMAND_LIST &&
    ++	(
    ++		. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" &&
    ++		GIT_COMPLETION_SHOW_ALL_COMMANDS=1 &&
    ++		export GIT_COMPLETION_SHOW_ALL_COMMANDS &&
    ++		sane_unset GIT_TESTING_PORCELAIN_COMMAND_LIST &&
     +
    -+	# Both mainporcelain and plumbing commands
    -+	run_completion "git c" &&
    -+	grep checkout out &&
    -+	grep cat-file out &&
    ++		# Both mainporcelain and plumbing commands
    ++		run_completion "git c" &&
    ++		grep checkout out &&
    ++		grep cat-file out &&
     +
    -+	# Check "gitk", a "main" command, but not a built-in + more plumbing
    -+	run_completion "git g" &&
    -+	grep gitk out &&
    -+	grep get-tar-commit-id out
    ++		# Check "gitk", a "main" command, but not a built-in + more plumbing
    ++		run_completion "git g" &&
    ++		grep gitk out &&
    ++		grep get-tar-commit-id out
    ++	)
     +'
     +
      test_expect_success '__git_complete' '

Change tests of git-completion.bash that re-source it to do so inside a subshell. Re-sourcing it will clobber variables it sets, and in the case of the "GIT_COMPLETION_SHOW_ALL=1" test added in ca2d62b7879 (parse-options: don't complete option aliases by default, 2021-07-16) change the behavior of the completion persistently.

Aside from the addition of "(" and ")" on new lines this is an indentation-only change, only the "(" and ")" lines are changed under "git diff -w".

So let's change that test, and for good measure do the same for the three tests that precede it, which were added in 8b0eaa41f23 (completion: clear cached --options when sourcing the completion script, 2018-03-22). The may not be wrong, but doing this establishes a more reliable pattern for future tests, which might use these as a template to copy.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 t/t9902-completion.sh | 50 +++++++++++++++++++++++++------------------
 1 file changed, 29 insertions(+), 21 deletions(-)

Add a GIT_COMPLETION_SHOW_ALL_COMMANDS=1 configuration setting to go with the existing GIT_COMPLETION_SHOW_ALL=1 added in c099f579b98 (completion: add GIT_COMPLETION_SHOW_ALL env var, 2020-08-19).

This will include plumbing commands such as "cat-file" in "git <TAB>" and "git c<TAB>" completion. Without/with this I have 134 and 243 completion with git <TAB>, respectively.

It was already possible to do this by tweaking GIT_TESTING_PORCELAIN_COMMAND_LIST= from the outside, that testing variable was added in 84a97131065 (completion: let git provide the completable command list, 2018-05-20). Doing this before loading git-completion.bash worked:

    export GIT_TESTING_PORCELAIN_COMMAND_LIST="$(git --list-cmds=builtins,main,list-mainporcelain,others,nohelpers,alias,list-complete,config)"

But such testing variables are not meant to be used from the outside, and we make no guarantees that those internal won't change. So let's expose this as a dedicated configuration knob.

It would be better to teach --list-cmds=* a new category which would include all of these groups, but that's a larger change that we can leave for some other time.

1. https://lore.kernel.org/git/CAGP6POJ9gwp+t-eP3TPkivBLLbNb2+qj=61Mehcj=1BgrVOSLA@mail.gmail.com/

Reported-by: Hongyi Zhao <hongyi.zhao@gmail.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 contrib/completion/git-completion.bash | 13 ++++++++++-
 t/t9902-completion.sh                  | 31 ++++++++++++++++++++++++++
 2 files changed, 43 insertions(+), 1 deletion(-)

On Wed, Feb 02, 2022 at 12:15:10PM +0100, Ævar Arnfjörð Bjarmason wrote:

I've tried this a couple of times in the last dozen years or so... and ended up hating it every single time, because it too often made completion of frequently used porcelain commands more cumbersome, and quickly reverted it.

Since 6532f3740b (completion: allow to customize the completable command list, 2018-05-20) it is possible to include and exclude certain commands from the list offered for 'git <TAB>'. So if you use some plumbing command frequently, then you can add them to the 'completion.commands' config variable, and they will show up for 'git <TAB>', too, without any of the other plumbing commands to get annoying.

To complete only rarely used plumbing commands in a non-intrusive way, in my experience, it's best to first attempt to complete only porcelains and aliases, and fall back to complete all commands, plumbing included, only when no porcelains match the current word to be completed. E.g.:

  $ git d<TAB>
  describe   diff   difftool
  $ git diff-<TAB>
  diff-files   diff-index   diff-tree

  $ git p<TAB>
  prune   pull    push    
  $ git pa<TAB>
  pack-objects     pack-redundant   pack-refs        patch-id 

  ---   >8   ---

Subject: [PATCH] completion: list all git commands as fallback

---
 contrib/completion/git-completion.bash | 3 +++
 1 file changed, 3 insertions(+)

SZEDER Gábor <szeder.dev@gmail.com> writes:

So after getting

    $ git diff<TAB>
    diff difftool

you _have_ to know, if you are not happy with these two, that the next letter in the name of the command you forgot is a dash, to be able to say

    $ git diff-<TAB>

which is a bit unfortunate, but I agree that it is much nicer than getting all the plumbing when trying to complete "git d<TAB>".

I wonder if we can do better, and teach the completion logic an ability to say this: "I gave 'diff and difftool' after being asked for 'git diff<TAB>' and then the user is asking the same again without choosing either. Perhaps I should add less frequent one to the mix"?

I.e. the end-user session may look like

    $ git diff<TAB>
    diff difftool
    $ git diff<TAB>
    diff difftool diff-files diff-index diff-tree

?

On Sun, Feb 06, 2022 at 12:09:35PM -0800, Junio C Hamano wrote:

Yeah, it can only save a couple of keystrokes, but it's not really useful when you want to use it to jog your memory. I naively assumed that if you use plumbing, then you know what you are doing and which command you want to execute :)

Hrm, interesting, but dunno. When completing commands in __git_main() we could save the current word to be completed in a variable, and when completing commands the next time we could check whether the current word is still the same, and then include plumbing as well. However, when the current word can't be uniquely completed, then we have to press TAB twice to get the list of possible completion, so we have to preserve the last two current words, and only list plumbing when both match.

  ---   >8   ---

SZEDER Gábor <szeder.dev@gmail.com> writes:

Yup, it always is tricky to "invalidate" a cached value.