patchbash completion: Add completion for 'git grep'

Added completions for all long options specified in the docs
	--cached
	--text --ignore-case --word-regexp --invert-match
	--full-name
	--extended-regexp --basic-regexp --fixed-strings
	--files-with-matches --name-only
	--files-without-match
	--count
	--and --or --not --all-match

Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
 contrib/completion/git-completion.bash |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

Lee Marlow <lee.marlow@gmail.com> wrote:

Hmm. The has_doubledash test seems redundant since we don't do anything with args that aren't --foo. Even though git-grep will accept a tree-ish and thus completion of __git_refs here may make sense.

I wonder if we shouldn't just add to the end something like:

	__gitcomp "$(__git_refs)"

like the _git_reset function does. Then we can complete a tree-ish for searching, as well as honor -- to stop tree-ish completion and go back to file/directory completion.

But that is very much a user question. Do users mostly search a file in the current working directory, or do they mostly search a tree-ish?

On Sat, Aug 2, 2008 at 3:05 PM, Shawn O. Pearce <spearce@spearce.org> wrote:

I haven't found myself using grep to search anything but the current working directory. I wonder whether __git_complete_file would be better than __git_refs. My issue with __git_complete_file in this case and also doing completion for 'git mv' is that it falls back to just __git_refs. Would it be better if it fell back to __git_refs and ls-tree for HEAD? That way when using completion to get to Documentation/git-grep.txt, it doesn't also show completions for Documentation/git-grep.{1,html,xml}.

-Lee

Lee Marlow <lee.marlow@gmail.com> wrote:

Hmm. __git_complete_file is about completing something in a tree-ish, which is really most likely not what we want for grep. Its useful for git-show and git-cat-file, and that's about it. Most git tools prefer a calling format of "tree-ish -- paths ..." and not "tree-ish:path".

Though I think you have an excellent point about completing paths by ls-tree for HEAD rather than the working directory itself, as then you can avoid produced files. But in practice how often do you pass a single file or a couple of files to the grep utility and are having problems bypassing the build products? Compared to just running grep on the entire source tree to find hits? I never use grep to search in a single file, but I call it several times a day to look for where a function is defined or called.

After having thought about it your original patch makes the most sense, but without the has_doubledash test.

Added completions for all long options specified in the docs
	--cached
	--text --ignore-case --word-regexp --invert-match
	--full-name
	--extended-regexp --basic-regexp --fixed-strings
	--files-with-matches --name-only
	--files-without-match
	--count
	--and --or --not --all-match

Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---

On Sun, Aug 3, 2008 at 10:06 PM, Shawn O. Pearce <spearce@spearce.org> wrote:

I think you're right that it's not a good fit for grep, but maybe for some other commands. mv and commit come to mind. I'll look into this as I'm trying to add completions for the more common (i.e. ones that I use) porcelain commands.

This updated patch removes the __git_has_doublehash line. However, I just noticed that d773c631 added __git_has_doublehash to prevent completions of long options after --. So, maybe it's not too redundant and my first patch might be better.

-Lee

 contrib/completion/git-completion.bash |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

Lee Marlow <lee.marlow@gmail.com> wrote:

Heh.  I forgot about that.  You're right, your first patch is better.

Lee Marlow <lee.marlow@gmail.com> wrote:

Acked-by: Shawn O. Pearce <spearce@spearce.org>

This is the "first patch" which has the doubledash test. As you pointed out, its better because it stops completion of long options after the --.