From: Shawn Pearce Date: Sat, 25 Nov 2006 07:13:51 GMT Subject: Re: Calling all bash completion experts.. Message-ID: <20061125071351.GE4528@spearce.org> In-Reply-To: Linus Torvalds wrote: > So I do "git repa" 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" would have acted). [snip] > 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? 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 maconcompgit-com 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 maconcompgit-com as each successive 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. --