# [RFC PATCH] bash completion: complete refs for git-grep 6 messages from 2009-10-06 to 2009-10-12. Participants: Thomas Rast, Shawn O. Pearce, Junio C Hamano. Thread: https://gitlist.dev/t/21139 ## Thomas Rast, 2009-10-06 10:08 Subject: [RFC PATCH] bash completion: complete refs for git-grep Message-ID: <14ac499280c9b17f862ab13201b48c64b4827713.1254823328.git.trast@student.ethz.ch> URL: https://gitlist.dev/e/14ac499280c9b17f862ab13201b48c64b4827713.1254823328.git.trast%40student.ethz.ch ``` Attempt ref completion once we have seen a regular expression, to help the user with entering the arguments. Signed-off-by: Thomas Rast --- The use-case for this is actually a bit protracted but came up on IRC yesterday: pasky asked if there was a simple way to grep through a certain file in all refs. Turns out git-grep already has half the required support: when given a series of refs, it prefixes the matches with the ref, so the output is already in a useful format. Sadly it does not appear to support --all, --branches or similar (which would be material for a separate patch). But bash completion can step in here: with M-*, it can expand all possible completions for the current word onto the command line. This is still RFC because, as you can see in the code below, I tried to avoid completing at all while the user still needs to supply a regex. Sadly, bash turns the COMPREPLY=() into filename completion anyway. Is there a way to prevent this? Otherwise the regex complication should probably just go away and we can complete refs always. contrib/completion/git-completion.bash | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 6fd7e1d..c8cced6 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1048,6 +1048,24 @@ _git_grep () return ;; esac + + local i c=1 have_regex="" + while [ $c -lt $COMP_CWORD ]; do + i="${COMP_WORDS[c]}" + case "$i" in + -e) ;; + -e*) have_regex="$c" ; break ;; + -*) ;; + *) have_regex="$c"; break ;; + esac + c=$((++c)) + done + + if [ -n "$have_regex" ]; then + __gitcomp "$(__git_refs)" + return + fi + COMPREPLY=() } -- 1.6.5.rc2.251.g34f85 ``` ## Shawn O. Pearce, 2009-10-06 15:45 Subject: Re: [RFC PATCH] bash completion: complete refs for git-grep Message-ID: <20091006154555.GN9261@spearce.org> URL: https://gitlist.dev/e/20091006154555.GN9261%40spearce.org In-Reply-To: <14ac499280c9b17f862ab13201b48c64b4827713.1254823328.git.trast@student.ethz.ch> ``` Thomas Rast wrote: > This is still RFC because, as you can see in the code below, I tried > to avoid completing at all while the user still needs to supply a > regex. Sadly, bash turns the COMPREPLY=() into filename completion > anyway. Is there a way to prevent this? Not that I know of. You can turn off default filename completion when you register the completion function, but that then breaks like every other git command for completion support because a lot of them do want to complete filenames. > + local i c=1 have_regex="" > + while [ $c -lt $COMP_CWORD ]; do > + i="${COMP_WORDS[c]}" > + case "$i" in > + -e) ;; > + -e*) have_regex="$c" ; break ;; > + -*) ;; > + *) have_regex="$c"; break ;; > + esac > + c=$((++c)) > + done What happens with `git grep -e a -e b`? Do we trigger into ref completion too early when we should still be doing the regex completion? -- Shawn. ``` ## Thomas Rast, 2009-10-07 15:27 Subject: Re: [RFC PATCH] bash completion: complete refs for git-grep Message-ID: <200910071727.50770.trast@student.ethz.ch> URL: https://gitlist.dev/e/200910071727.50770.trast%40student.ethz.ch In-Reply-To: <20091006154555.GN9261@spearce.org> ``` Shawn O. Pearce wrote: > > Thomas Rast wrote: > > + local i c=1 have_regex="" > > + while [ $c -lt $COMP_CWORD ]; do > > + i="${COMP_WORDS[c]}" > > + case "$i" in > > + -e) ;; > > + -e*) have_regex="$c" ; break ;; > > + -*) ;; > > + *) have_regex="$c"; break ;; > > + esac > > + c=$((++c)) > > + done > > What happens with `git grep -e a -e b`? Do we trigger into ref > completion too early when we should still be doing the regex > completion? Hmm, true, I would also have to check for the last argument (before completion) being -e. However, that is kind of moot because we currently complete filenames anyway, and you said I can't stop that: > > This is still RFC because, as you can see in the code below, I tried > > to avoid completing at all while the user still needs to supply a > > regex. Sadly, bash turns the COMPREPLY=() into filename completion > > anyway. Is there a way to prevent this? > > Not that I know of. You can turn off default filename completion > when you register the completion function, but that then breaks > like every other git command for completion support because a lot > of them do want to complete filenames. So I'll roll a simpler patch that just always (before --) completes refs instead, if that's ok. -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## Thomas Rast, 2009-10-12 09:00 Subject: [PATCH] bash completion: complete refs for git-grep Message-ID: <9f58ba1e7db9702d1b0594a8016c204e3d50b72f.1255337776.git.trast@student.ethz.ch> URL: https://gitlist.dev/e/9f58ba1e7db9702d1b0594a8016c204e3d50b72f.1255337776.git.trast%40student.ethz.ch In-Reply-To: <200910071727.50770.trast@student.ethz.ch> ``` Before the --, always attempt ref completion. This helps with entering the arguments to git-grep. As a bonus, you can work around git-grep's current lack of --all by hitting M-*, ugly as the resulting command line may be. Strictly speaking, completing the regular expression argument (or option argument) makes no sense. However, we cannot prevent _all_ completion (it will fall back to filenames), so we dispense with any additional complication to detect whether the user still has to enter a regular expression. Signed-off-by: Thomas Rast --- Sorry for taking so long; I was swamped all weekend by, well, the weekend. ;-) I wrote: > Shawn O. Pearce wrote: > > > This is still RFC because, as you can see in the code below, I tried > > > to avoid completing at all while the user still needs to supply a > > > regex. Sadly, bash turns the COMPREPLY=() into filename completion > > > anyway. Is there a way to prevent this? > > > > Not that I know of. You can turn off default filename completion > > when you register the completion function, but that then breaks > > like every other git command for completion support because a lot > > of them do want to complete filenames. > > So I'll roll a simpler patch that just always (before --) completes > refs instead, if that's ok. So that's what this patch does. contrib/completion/git-completion.bash | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 6fd7e1d..b08cd77 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1048,7 +1048,8 @@ _git_grep () return ;; esac - COMPREPLY=() + + __gitcomp "$(__git_refs)" } _git_help () -- 1.6.5.61.g35405 ``` ## Shawn O. Pearce, 2009-10-12 14:27 Subject: Re: [PATCH] bash completion: complete refs for git-grep Message-ID: <20091012142710.GI9261@spearce.org> URL: https://gitlist.dev/e/20091012142710.GI9261%40spearce.org In-Reply-To: <9f58ba1e7db9702d1b0594a8016c204e3d50b72f.1255337776.git.trast@student.ethz.ch> ``` Thomas Rast wrote: > > So I'll roll a simpler patch that just always (before --) completes > > refs instead, if that's ok. Hard to argue with that logic. :-) Acked-by: Shawn O. Pearce > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash > index 6fd7e1d..b08cd77 100755 > --- a/contrib/completion/git-completion.bash > +++ b/contrib/completion/git-completion.bash > @@ -1048,7 +1048,8 @@ _git_grep () > return > ;; > esac > - COMPREPLY=() > + > + __gitcomp "$(__git_refs)" > } -- Shawn. ``` ## Junio C Hamano, 2009-10-12 23:42 Subject: Re: [PATCH] bash completion: complete refs for git-grep Message-ID: <7v4oq46uyd.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v4oq46uyd.fsf%40alter.siamese.dyndns.org In-Reply-To: <20091012142710.GI9261@spearce.org> ``` "Shawn O. Pearce" writes: > Thomas Rast wrote: >> > So I'll roll a simpler patch that just always (before --) completes >> > refs instead, if that's ok. > > Hard to argue with that logic. :-) > > Acked-by: Shawn O. Pearce Thanks. > >> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash >> index 6fd7e1d..b08cd77 100755 >> --- a/contrib/completion/git-completion.bash >> +++ b/contrib/completion/git-completion.bash >> @@ -1048,7 +1048,8 @@ _git_grep () >> return >> ;; >> esac >> - COMPREPLY=() >> + >> + __gitcomp "$(__git_refs)" >> } > > -- > Shawn. > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ```