Calling all bash completion experts..

So, I'm a happy but clueless user of the bash completion, and one thing drives me wild: when it has found an exclusive completion, it doesn't add the final space at the end, but just beeps at you when you <tab> again.

So I do "git repa<tab>" and get "git repack", which is fine, but I really _wanted_ to get "git repack " (with the space at the end), since I've now got a unique command, and that's the normal completion behaviour (ie I want it to act the same way that "git-repa<tab>" would have acted).

The same is true of filename arguments, btw:

	git commit cont<tab>com<tab><tab>

gives me

	git commit contrib/completion/git-completion.bash

but again, it doesn't seem to do the right thing about the fact that it was the unique choice, so it didn't add the final space, and when you press <tab> more to get what the other choices are, it doesn't show you any other choices (because there are none).

Now, without knowing the completion syntax, I assume it's the "-o nospace" things in the completion file. So I'm wondering _why_ that "nospace" is there, and whether this could be fixed?

Linus Torvalds <torvalds@osdl.org> wrote:

[snip]

Yes, its the "-o nospace".

I added the nospace option because of the completion for fetch/push, cat-file, diff-tree and ls-tree.

The problem is the file completion for e.g. cat-file. We don't want a space added after we complete a directory name, so you can complete further, e.g.:

  git cat-file -p ma<tab>con<tab>comp<tab>git-com<tab>

gives us:

  git cat-file -p master:contrib/completion/git-completion.sh

but if I omitted the "-o nospace" then we would instead need:

  git cat-file ma<tab><bs>con<tab><bs>comp<tab><bs>git-com<tab>

as each successive <tab> would add a trailing space that you would need to remove before you can complete again.

So as a user I decided that adding the space myself was less annoying then needing to delete the space during completion down through a tree. But perhaps that was wrong.

I did try to inject the space myself in the completion code when I knew something was unique, but bash didn't like that (it tossed the space).

To be honest, I'm not really sure how to fix it.

One option would be to perform a `ls-tree -r` through whatever part of the path we have now and offer up EVERYTHING in the tree as a possible completion, but that is insane as it will take a little while to generate and on a large tree (e.g. the Linux kernel) you will get a large number of proposed completions back which aren't really relevant.

On Sat, 25 Nov 2006, Shawn Pearce wrote:

But that's how directory completion _always_ works. Completion doesn't add spaces to directories anyway, it adds a "/".

The branch-name thing is well-taken: you don't want to add a space after a branch-name, although neither do you want to add a ":" by default.

So "nospace" after a branch (or tag) name sounds sane, but nowhere else that I can see.

Linus Torvalds <torvalds@osdl.org> wrote:

All in all what you are asking is reasonable. Users really should expect the Git completion to work just like any other completion built-in to bash. I've just run into some difficulty making that be the case with all of the git commands. :)

I'm trying to push really hard on git-gui right now, to get it to the point that people who are absolutely terrified of the command line can still do basic operations (commit, fetch, trivial merge, push). 'cause I really need to get a some of those users onto a git repository (like everyone else) rather than an unbacked-up network share which has no revision history.

I'll come back to the bash completion soon. Jakub Narebski and another person have both asked that I do some more work for other commands. I was hoping that other person might do some of the modifications himself and contribute them back, but it looks like he's just as busy as I am and hasn't found the time.