[completion] Request: Include remote heads as push targets

[completion] Request: Include remote heads as push targets

[Marc Branchaud]

Hi Shawn,

I find myself wishing that completion would support the following:

	git push origin HEAD:<tab>

The options presented at this point should include all the origin/* heads,
without the "origin/" prefix.  Right now (git 1.7.3.1) completion only lets
me choose from local refs.

I tried looking at the completion script myself, but my completion-fu is weak
and I'm really not sure how to go about implementing this.

So I'm just throwing this request out to see what happens.

Thanks!

		M.

Re: [completion] Request: Include remote heads as push targets

[Marc Branchaud]

On 10-10-21 11:37 AM, Marc Branchaud wrote:
> Hi Shawn,
> 
> I find myself wishing that completion would support the following:
> 
> 	git push origin HEAD:<tab>
> 
> The options presented at this point should include all the origin/* heads,
> without the "origin/" prefix.  Right now (git 1.7.3.1) completion only lets
> me choose from local refs.

Hmmm, perhaps this is really a bug.

When I double-tab, the remote branch name I want is in the list of
possibilities.  But when I try to complete by typing a couple of leading
characters then hitting <tab> again, I don't get that name.  Instead I get a
tag that starts with the same letters.

More concretely:

$ echo $BASH_VERSION
4.1.5(1)-release

$ git branch -a
  bar
  baz
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/battle
  remotes/origin/battle.hardened
  remotes/origin/master

$ git tag
bassinet

$ git push origin HEAD:<tab><tab>
battle            battle.hardened   HEAD              master

$ git push origin HEAD:ba<tab><tab>
bar        bassinet   baz

Wacky!

		M.

Re: [completion] Request: Include remote heads as push targets

[Jonathan Nieder]

Marc Branchaud wrote:

> Hmmm, perhaps this is really a bug.

Compare:
http://thread.gmane.org/gmane.comp.version-control.git/159448

Gábor, would it be possible to summarize the problem with a simple
test case that could be used to get help on this from the (upstream
or distro-specific) bash maintainers?

Re: [completion] Request: Include remote heads as push targets

[Peter van der Does]

On Thu, 21 Oct 2010 14:10:45 -0500
Jonathan Nieder <jrnieder@gmail.com> wrote:

> Marc Branchaud wrote:
> 
> > Hmmm, perhaps this is really a bug.
> 
> Compare:
> http://thread.gmane.org/gmane.comp.version-control.git/159448
> 
> Gábor, would it be possible to summarize the problem with a simple
> test case that could be used to get help on this from the (upstream
> or distro-specific) bash maintainers?
> --

In the case of Marc's problem, it would be helpful to see what the
result is in Bash 3.

As for Gábor find:
The problem resides in Bash 4. Bash 4 has a new set of characters that
are defined as break up characters
Thanks to Brain Gernhard: 
From the Bash 4.0 changelog:
i.  The programmable completion code now uses the same set of
characters as readline when breaking the command line into a list of
words.

As far as I can tell, from the Bash 4.0 source, these are the
characters: " \t\n\"'@><=;|&(:" 
In the completion script checks are performed if an option is given.
The test includes the equal sign but the array with words does not the
equal sign. Example to clarify:

local cur="${COMP_WORDS[COMP_CWORD]}" dir="$(__gitdir)"
case "$cur" in
  --whitespace=*)
      __gitcomp "$__git_whitespacelist" "" "${cur##--whitespace=}"
      return
      ;;

If you execute:
$ git am --whitespace=<tab><tab>

The variable cur holds the equal sign and so the __gitcomp function is
never executed.

I have patched the entire completion script which fixes this, and some
other issues related to the Bash 4 change, but it will only work in Bash
4.0 and I am sure it will dramatically fail in Bash 3.0.
I don't have the knowledge to determine which Bash version is running
in the git.spec.in file. If you could that would be a way to either
install the new version or the old one.


-- 
Peter van der Does

GPG key: E77E8E98

IRC: Ganseki on irc.freenode.net
Twitter: @petervanderdoes

WordPress Plugin Developer
Blog: http://blog.avirtualhome.com
Forums: http://forums.avirtualhome.com
Twitter: @avhsoftware

Re: [completion] Request: Include remote heads as push targets

[Kevin Ballard]

On Oct 21, 2010, at 6:08 PM, Peter van der Does wrote:

> I don't have the knowledge to determine which Bash version is running
> in the git.spec.in file. If you could that would be a way to either
> install the new version or the old one.

Could you instead teach the script how to work on both Bash 3 or Bash 4? If you could extract the references to the completion words into a function, you could define one function for Bash 3 and one for Bash 4, and use ${BASH_VERSINFO[0]} to determine which to use.

-Kevin Ballard

Re: [completion] Request: Include remote heads as push targets

[Marc Branchaud]

On 10-10-21 09:08 PM, Peter van der Does wrote:
> 
> In the case of Marc's problem, it would be helpful to see what the
> result is in Bash 3.

Bash v3 seems to work fine:

$ echo $BASH_VERSION
3.2.0(1)-release

$ git branch -a
  bar
  baz
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/battle
  remotes/origin/battle.hardened
  remotes/origin/master

$ git tag
bassinet

$ git push origin HEAD:<tab><tab>
battle            battle.hardened   HEAD              master

$ git push origin HEAD:ba<tab>
  git push origin HEAD:battle<tab><tab>
battle            battle.hardened

		M.

Re: [completion] Request: Include remote heads as push targets

[SZEDER Gábor]

Hi,


On Thu, Oct 21, 2010 at 09:08:42PM -0400, Peter van der Does wrote:
> On Thu, 21 Oct 2010 14:10:45 -0500
> Jonathan Nieder <jrnieder@gmail.com> wrote:
> 
> > Marc Branchaud wrote:
> > 
> > > Hmmm, perhaps this is really a bug.
> > 
> > Compare:
> > http://thread.gmane.org/gmane.comp.version-control.git/159448

Yeah, it seems that the two issues are related.  I can confirm what
Marc saw, and below is a PoC patch to fix it.

> In the case of Marc's problem, it would be helpful to see what the
> result is in Bash 3.

On an oldish server with bash 3.2 it works as expected, i.e. I get
only the matching branches and tags from the remote repo.

(Sidenote: hm, offering _tags_ to _push to_?!  That doesn't seem quite
right at first sight.)


> > Gábor, would it be possible to summarize the problem with a simple
> > test case that could be used to get help on this from the (upstream
> > or distro-specific) bash maintainers?

Git's bash completion is not the first to suffer from changes in bash
4, and fortunately the bash-completion developers already provide a
solution for such issues.  Details below.

> As for Gábor find:
> The problem resides in Bash 4.

I agree.

> Bash 4 has a new set of characters that
> are defined as break up characters
> Thanks to Brain Gernhard: 
> From the Bash 4.0 changelog:
> i.  The programmable completion code now uses the same set of
> characters as readline when breaking the command line into a list of
> words.
> 
> As far as I can tell, from the Bash 4.0 source, these are the
> characters: " \t\n\"'@><=;|&(:" 

Um, well, I suspect that there are other subtle differences between
bash 4 and 3 besides the change of word-breaking characters that
trigger this breakage.  In fact, the oldish server mentioned above
with bash 3.2 has the exact same characters in $COMP_WORDBREAKS, and
neither Marc's nor my issue occur there.

> In the completion script checks are performed if an option is given.
> The test includes the equal sign but the array with words does not the
> equal sign. Example to clarify:
> 
> local cur="${COMP_WORDS[COMP_CWORD]}" dir="$(__gitdir)"
> case "$cur" in
>   --whitespace=*)
>       __gitcomp "$__git_whitespacelist" "" "${cur##--whitespace=}"
>       return
>       ;;
> 
> If you execute:
> $ git am --whitespace=<tab><tab>
> 
> The variable cur holds the equal sign and so the __gitcomp function is
> never executed.

That's exactly what I observed.  This ${COMP_WORDS[COMP_CWORD]}
construct apparently is not the right way to find the word to complete
anymore, assuming you want your completion script to work with bash 4
and 3 as well.  Unfortunately, we use this construct all over the
place.

Now, the bash completion project has some functions that could be used
to circumvent these issues.  In particular, look at the description of
the _get_comp_words_by_ref() function here, especially at the -n
option:

http://git.debian.org/?p=bash-completion/bash-completion.git;a=blob;f=bash_completion;h=589c2e5afe283d2e6d7628b683ae6714ab70d3d9;hb=HEAD#l371

That would allow us to remove characters from $COMP_WORDBREAKS on a
per-function basis, without influencing unrelated completion functions
within or outside of git completion, and in a way that works with bash
4 and 3 as well.

Here is a proof of concept patch to use that function instead of
${COMP_WORDS[COMP_CWORD]} in two places.  The second hunk fixes the
completion of pretty aliases for 'git log --pretty='.  The first hunk
seems to fix Marc's issue with the completion of remotes after 'git
push origin HEAD:', but I haven't thought this one through (there's a
lot going on with scanning the previous words on the command line and
such, so it might actually break something else).  Both fixes seem to
work under bash 4 and 3.2.

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index f83f019..5608e9b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -551,7 +551,8 @@ __git_complete_revlist ()
 __git_complete_remote_or_refspec ()
 {
 	local cmd="${COMP_WORDS[1]}"
-	local cur="${COMP_WORDS[COMP_CWORD]}"
+	local cur
+	_get_comp_words_by_ref -n ':' cur
 	local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
 	while [ $c -lt $COMP_CWORD ]; do
 		i="${COMP_WORDS[c]}"
@@ -1360,7 +1361,8 @@ _git_log ()
 {
 	__git_has_doubledash && return
 
-	local cur="${COMP_WORDS[COMP_CWORD]}"
+	local cur
+	_get_comp_words_by_ref -n '=' cur
 	local g="$(git rev-parse --git-dir 2>/dev/null)"
 	local merge=""
 	if [ -f "$g/MERGE_HEAD" ]; then

This patch assumes that you use fairly recent bash-completion, because
_get_comp_words_by_ref() was first included in bash-completion v1.2,
which was released just this summer.

However, git completion is currently a standalone completion script,
i.e. to use it you need only bash, git-completion.bash, and nothing
else.  If we start to use _get_comp_words_by_ref() directly, as in the
PoC patch above, then git completion will inherently depend on
bash-completion, too.  This could be considered as a regression.

Alternatively, we could just copy the necessary functions from
bash-completion to git-completion.bash (with the name changed, of
course, e.g. to __git_get_comp_words_by_ref()), keeping git completion
standalone but still getting the benefits of this function, and
getting these bash 4 vs. 3 issues fixed.

Thoughts?


Best,
Gábor

Re: [completion] Request: Include remote heads as push targets

[Peter van der Does]

On Sat, 23 Oct 2010 15:04:34 +0200
SZEDER Gábor <szeder@ira.uka.de> wrote:


> Here is a proof of concept patch to use that function instead of
> ${COMP_WORDS[COMP_CWORD]} in two places.  The second hunk fixes the
> completion of pretty aliases for 'git log --pretty='.  The first hunk
> seems to fix Marc's issue with the completion of remotes after 'git
> push origin HEAD:', but I haven't thought this one through (there's a
> lot going on with scanning the previous words on the command line and
> such, so it might actually break something else).  Both fixes seem to
> work under bash 4 and 3.2.
> 
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash index f83f019..5608e9b 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -551,7 +551,8 @@ __git_complete_revlist ()
>  __git_complete_remote_or_refspec ()
>  {
>  	local cmd="${COMP_WORDS[1]}"
> -	local cur="${COMP_WORDS[COMP_CWORD]}"
> +	local cur
> +	_get_comp_words_by_ref -n ':' cur
>  	local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
>  	while [ $c -lt $COMP_CWORD ]; do
>  		i="${COMP_WORDS[c]}"
> @@ -1360,7 +1361,8 @@ _git_log ()
>  {
>  	__git_has_doubledash && return
>  
> -	local cur="${COMP_WORDS[COMP_CWORD]}"
> +	local cur
> +	_get_comp_words_by_ref -n '=' cur
>  	local g="$(git rev-parse --git-dir 2>/dev/null)"
>  	local merge=""
>  	if [ -f "$g/MERGE_HEAD" ]; then
> 
> This patch assumes that you use fairly recent bash-completion, because
> _get_comp_words_by_ref() was first included in bash-completion v1.2,
> which was released just this summer.
> 
> However, git completion is currently a standalone completion script,
> i.e. to use it you need only bash, git-completion.bash, and nothing
> else.  If we start to use _get_comp_words_by_ref() directly, as in the
> PoC patch above, then git completion will inherently depend on
> bash-completion, too.  This could be considered as a regression.
> 
> Alternatively, we could just copy the necessary functions from
> bash-completion to git-completion.bash (with the name changed, of
> course, e.g. to __git_get_comp_words_by_ref()), keeping git completion
> standalone but still getting the benefits of this function, and
> getting these bash 4 vs. 3 issues fixed.
> 
> Thoughts?
> 

Instead of using [code]_get_comp_words_by_ref -n '=' cur[/code] you can
use [code]local cur=`_get_cword "="`[/code].

To keep git completion standalone we need to, like Gábor mentioned, add
the necessary functions, but we don't have to rename them. There is
an option to check if a function exists. I've changed the entire git
completion script and hopefully covered all options. From my tests it
works on bash 4.

To give an idea of what the change is, here's part of the entire diff.

diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash index f83f019..a2c0589 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -71,12 +71,159 @@
 #
 #       git@vger.kernel.org
 #
+# Updated for Bash 4.0
 
 case "$COMP_WORDBREAKS" in
 *:*) : great ;;
 *)   COMP_WORDBREAKS="$COMP_WORDBREAKS:"
 esac
 
+# If the function _get_cword does not exists, we can assume the
+# bash_completion script isn't loaded and therefor we're defining the
+# necessary functions ourselves.
+if ! type _get_cword &> /dev/null ; then
+	# features supported by bash 4.0 and higher
+	if [ ${BASH_VERSINFO[0]} -gt 3 ]; then
+	    declare -r git_bash4=$BASH_VERSION 2>/dev/null || :
+	fi
+
+	# Get the word to complete.
+	# This is nicer than ${COMP_WORDS[$COMP_CWORD]}, since it
handles cases
+	# where the user is completing in the middle of a word.
+	# (For example, if the line is "ls foobar",
+	# and the cursor is here -------->   ^
+	# it will complete just "foo", not "foobar", which is what the
user wants.)
+	# @param $1 string  (optional) Characters out of
$COMP_WORDBREAKS which should
+	#     NOT be considered word breaks. This is useful for things
like scp where
+	#     we want to return host:path and not only path.
+	#     NOTE: This parameter only applies to bash-4.
+	_get_cword()
+	{
+    	if [ -n "$git_bash4" ] ; then
+        	__get_cword4 "$@"
+    	else
+        	__get_cword3
+    	fi
+	} # _get_cword()
+
+
+	# Get the word to complete on bash-3, where words are not
broken by
+	# COMP_WORDBREAKS characters and the COMP_CWORD variables look
like this, for
+	# example:
+	#
+	#     $ a b:c<TAB>
+	#     COMP_CWORD: 1
+	#     COMP_CWORDS:
+	#     0: a
+	#     1: b:c
+	#
+	# See also:
+	# _get_cword, main routine
+	# __get_cword4, bash-4 variant
+	#
+	__get_cword3()
+	{
+	    if [[ "${#COMP_WORDS[COMP_CWORD]}" -eq 0 ]] ||
[[ "$COMP_POINT" == "${#COMP_LINE}" ]]; then
+        	printf "%s" "${COMP_WORDS[COMP_CWORD]}"
+    	else
+	        local i
+        	local cur="$COMP_LINE"
+        	local index="$COMP_POINT"
+        	for (( i = 0; i <= COMP_CWORD; ++i )); do
+	            while [[
+                	# Current COMP_WORD fits in $cur?
+                	"${#cur}" -ge ${#COMP_WORDS[i]} &&
+                	# $cur doesn't match COMP_WORD?
+                	"${cur:0:${#COMP_WORDS[i]}}" !=
"${COMP_WORDS[i]}"
+                	]]; do
+                	# Strip first character
+                	cur="${cur:1}"
+                	# Decrease cursor position
+                	index="$(( index - 1 ))"
+            	done
+	
+            	# Does found COMP_WORD matches COMP_CWORD?
+            	if [[ "$i" -lt "$COMP_CWORD" ]]; then
+	                # No, COMP_CWORD lies further;
+                	local old_size="${#cur}"
+                	cur="${cur#${COMP_WORDS[i]}}"
+                	local new_size="${#cur}"
+                	index="$(( index - old_size + new_size ))"
+            	fi
+        	done
+
+	        if [[ "${COMP_WORDS[COMP_CWORD]:0:${#cur}}" !=
"$cur" ]]; then
+            	# We messed up! At least return the whole word so
things
+            	# keep working
+            	printf "%s" "${COMP_WORDS[COMP_CWORD]}"
+        	else
+	            printf "%s" "${cur:0:$index}"
+        	fi
+    	fi
+	} # __get_cword3()
+
+
+	# Get the word to complete on bash-4, where words are splitted
by
+	# COMP_WORDBREAKS characters (default is " \t\n\"'><=;|&(:")
and the COMP_CWORD
+	# variables look like this, for example:
+	#
+	#     $ a b:c<TAB>
+	#     COMP_CWORD: 3
+	#     COMP_CWORDS:
+	#     0: a
+	#     1: b
+	#     2: :
+	#     3: c
+	#
+	# @oaram $1 string
+	# $1 string  (optional) Characters out of $COMP_WORDBREAKS
which should
+	#     NOT be considered word breaks. This is useful for things
like scp where
+	#     we want to return host:path and not only path.
+	# See also:
+	# _get_cword, main routine
+	# __get_cword3, bash-3 variant
+	#
+	__get_cword4()
+	{
+	    local i
+	    local LC_CTYPE=C
+	    local WORDBREAKS=$COMP_WORDBREAKS
+	    # Strip single quote (') and double quote (") from
WORDBREAKS to
+	    # workaround a bug in bash-4.0, where quoted words are
split
+	    # unintended, see:
+	    #
http://www.mail-archive.com/bug-bash@gnu.org/msg06095.html
+	    # This fixes simple quoting (e.g. $ a "b<TAB> returns "b
instead of b)
+	    # but still fails quoted spaces (e.g. $ a "b c<TAB>
returns c instead
+	    # of "b c).
+	    WORDBREAKS=${WORDBREAKS//\"/}
+	    WORDBREAKS=${WORDBREAKS//\'/}
+	    if [ -n "$1" ]; then
+        	for (( i=0; i<${#1}; ++i )); do
+	            local char=${1:$i:1}
+            	WORDBREAKS=${WORDBREAKS//$char/}
+        	done
+    	fi
+    	local cur=${COMP_LINE:0:$COMP_POINT}
+    	local tmp=$cur
+    	local word_start=`expr "$tmp" : '.*['"$WORDBREAKS"']'`
+    	while [ "$word_start" -ge 2 ]; do
+	        # Get character before $word_start
+        	local char=${cur:$(( $word_start - 2 )):1}
+        	# If the WORDBREAK character isn't escaped, exit loop
+        	if [ "$char" != "\\" ]; then
+	            break
+        	fi
+        	# The WORDBREAK character is escaped;
+        	# Recalculate $word_start
+        	tmp=${COMP_LINE:0:$(( $word_start - 2 ))}
+        	word_start=`expr "$tmp" : '.*['"$WORDBREAKS"']'`
+    	done
+
+	    cur=${cur:$word_start}
+	    printf "%s" "$cur"
+	} # __get_cword4()
+fi
+
@@ -551,7 +698,7 @@ __git_complete_revlist ()
 __git_complete_remote_or_refspec ()
 {
 	local cmd="${COMP_WORDS[1]}"
-	local cur="${COMP_WORDS[COMP_CWORD]}"
+	local cur=`_get_cword ":"`
 	local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
 	while [ $c -lt $COMP_CWORD ]; do
 		i="${COMP_WORDS[c]}"
@@ -1360,7 +1508,7 @@ _git_log ()
 {
 	__git_has_doubledash && return
 
-	local cur="${COMP_WORDS[COMP_CWORD]}"
+	local cur=`_get_cword "="`
 	local g="$(git rev-parse --git-dir 2>/dev/null)"
 	local merge=""
 	if [ -f "$g/MERGE_HEAD" ]; then
@@ -1419,7 +1567,7 @@ _git_merge ()
 {
 	__git_complete_strategy && return
 
-	local cur="${COMP_WORDS[COMP_CWORD]}"
+	local cur=`_get_cword`
 	case "$cur" in
 	--*)
 		__gitcomp "$__git_merge_options"


I just need someone to test the new script on Bash 3. If somebody is
willing to test, drop me an private email and I can send the new script.

Peter

-- 
GPG key: E77E8E98

IRC: Ganseki on irc.freenode.net
Twitter: @petervanderdoes

WordPress Plugin Developer
Blog: http://blog.avirtualhome.com
Forums: http://forums.avirtualhome.com
Twitter: @avhsoftware

Re: [completion] Request: Include remote heads as push targets

[SZEDER Gábor]

On Sat, Oct 23, 2010 at 08:07:39PM -0400, Peter van der Does wrote:
> On Sat, 23 Oct 2010 15:04:34 +0200
> SZEDER Gábor <szeder@ira.uka.de> wrote:
>
> > This patch assumes that you use fairly recent bash-completion, because
> > _get_comp_words_by_ref() was first included in bash-completion v1.2,
> > which was released just this summer.
> > 
> > However, git completion is currently a standalone completion script,
> > i.e. to use it you need only bash, git-completion.bash, and nothing
> > else.  If we start to use _get_comp_words_by_ref() directly, as in the
> > PoC patch above, then git completion will inherently depend on
> > bash-completion, too.  This could be considered as a regression.
> > 
> > Alternatively, we could just copy the necessary functions from
> > bash-completion to git-completion.bash (with the name changed, of
> > course, e.g. to __git_get_comp_words_by_ref()), keeping git completion
> > standalone but still getting the benefits of this function, and
> > getting these bash 4 vs. 3 issues fixed.
> > 
> > Thoughts?
> > 
> 
> Instead of using [code]_get_comp_words_by_ref -n '=' cur[/code] you can
> use [code]local cur=`_get_cword "="`[/code].
> 
> To keep git completion standalone we need to, like Gábor mentioned, add
> the necessary functions, but we don't have to rename them. There is
> an option to check if a function exists. I've changed the entire git
> completion script and hopefully covered all options. From my tests it
> works on bash 4.

Checking for the function first, and declaring it if it doesn't exists
could be a viewable alternative, but not with _get_cword().  The
_get_cword() implementation you are adding below is outdated.  It is
from bash-completion 1.1, changed quite a bit after that, and in the
end became deprecated in 1.2 in favor of _get_comp_words_by_ref().


> To give an idea of what the change is, here's part of the entire diff.
> 
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash index f83f019..a2c0589 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -71,12 +71,159 @@
>  #
>  #       git@vger.kernel.org
>  #
> +# Updated for Bash 4.0
>  
>  case "$COMP_WORDBREAKS" in
>  *:*) : great ;;
>  *)   COMP_WORDBREAKS="$COMP_WORDBREAKS:"
>  esac
>  
> +# If the function _get_cword does not exists, we can assume the
> +# bash_completion script isn't loaded and therefor we're defining the
> +# necessary functions ourselves.
> +if ! type _get_cword &> /dev/null ; then
> +	# features supported by bash 4.0 and higher
> +	if [ ${BASH_VERSINFO[0]} -gt 3 ]; then
> +	    declare -r git_bash4=$BASH_VERSION 2>/dev/null || :
> +	fi
> +
> +	# Get the word to complete.
> +	# This is nicer than ${COMP_WORDS[$COMP_CWORD]}, since it
> handles cases
> +	# where the user is completing in the middle of a word.
> +	# (For example, if the line is "ls foobar",
> +	# and the cursor is here -------->   ^
> +	# it will complete just "foo", not "foobar", which is what the
> user wants.)
> +	# @param $1 string  (optional) Characters out of
> $COMP_WORDBREAKS which should
> +	#     NOT be considered word breaks. This is useful for things
> like scp where
> +	#     we want to return host:path and not only path.
> +	#     NOTE: This parameter only applies to bash-4.
> +	_get_cword()
> +	{
> +    	if [ -n "$git_bash4" ] ; then
> +        	__get_cword4 "$@"
> +    	else
> +        	__get_cword3
> +    	fi
> +	} # _get_cword()
> +
> +
> +	# Get the word to complete on bash-3, where words are not
> broken by
> +	# COMP_WORDBREAKS characters and the COMP_CWORD variables look
> like this, for
> +	# example:
> +	#
> +	#     $ a b:c<TAB>
> +	#     COMP_CWORD: 1
> +	#     COMP_CWORDS:
> +	#     0: a
> +	#     1: b:c
> +	#
> +	# See also:
> +	# _get_cword, main routine
> +	# __get_cword4, bash-4 variant
> +	#
> +	__get_cword3()
> +	{
> +	    if [[ "${#COMP_WORDS[COMP_CWORD]}" -eq 0 ]] ||
> [[ "$COMP_POINT" == "${#COMP_LINE}" ]]; then
> +        	printf "%s" "${COMP_WORDS[COMP_CWORD]}"
> +    	else
> +	        local i
> +        	local cur="$COMP_LINE"
> +        	local index="$COMP_POINT"
> +        	for (( i = 0; i <= COMP_CWORD; ++i )); do
> +	            while [[
> +                	# Current COMP_WORD fits in $cur?
> +                	"${#cur}" -ge ${#COMP_WORDS[i]} &&
> +                	# $cur doesn't match COMP_WORD?
> +                	"${cur:0:${#COMP_WORDS[i]}}" !=
> "${COMP_WORDS[i]}"
> +                	]]; do
> +                	# Strip first character
> +                	cur="${cur:1}"
> +                	# Decrease cursor position
> +                	index="$(( index - 1 ))"
> +            	done
> +	
> +            	# Does found COMP_WORD matches COMP_CWORD?
> +            	if [[ "$i" -lt "$COMP_CWORD" ]]; then
> +	                # No, COMP_CWORD lies further;
> +                	local old_size="${#cur}"
> +                	cur="${cur#${COMP_WORDS[i]}}"
> +                	local new_size="${#cur}"
> +                	index="$(( index - old_size + new_size ))"
> +            	fi
> +        	done
> +
> +	        if [[ "${COMP_WORDS[COMP_CWORD]:0:${#cur}}" !=
> "$cur" ]]; then
> +            	# We messed up! At least return the whole word so
> things
> +            	# keep working
> +            	printf "%s" "${COMP_WORDS[COMP_CWORD]}"
> +        	else
> +	            printf "%s" "${cur:0:$index}"
> +        	fi
> +    	fi
> +	} # __get_cword3()
> +
> +
> +	# Get the word to complete on bash-4, where words are splitted
> by
> +	# COMP_WORDBREAKS characters (default is " \t\n\"'><=;|&(:")
> and the COMP_CWORD
> +	# variables look like this, for example:
> +	#
> +	#     $ a b:c<TAB>
> +	#     COMP_CWORD: 3
> +	#     COMP_CWORDS:
> +	#     0: a
> +	#     1: b
> +	#     2: :
> +	#     3: c
> +	#
> +	# @oaram $1 string
> +	# $1 string  (optional) Characters out of $COMP_WORDBREAKS
> which should
> +	#     NOT be considered word breaks. This is useful for things
> like scp where
> +	#     we want to return host:path and not only path.
> +	# See also:
> +	# _get_cword, main routine
> +	# __get_cword3, bash-3 variant
> +	#
> +	__get_cword4()
> +	{
> +	    local i
> +	    local LC_CTYPE=C
> +	    local WORDBREAKS=$COMP_WORDBREAKS
> +	    # Strip single quote (') and double quote (") from
> WORDBREAKS to
> +	    # workaround a bug in bash-4.0, where quoted words are
> split
> +	    # unintended, see:
> +	    #
> http://www.mail-archive.com/bug-bash@gnu.org/msg06095.html
> +	    # This fixes simple quoting (e.g. $ a "b<TAB> returns "b
> instead of b)
> +	    # but still fails quoted spaces (e.g. $ a "b c<TAB>
> returns c instead
> +	    # of "b c).
> +	    WORDBREAKS=${WORDBREAKS//\"/}
> +	    WORDBREAKS=${WORDBREAKS//\'/}
> +	    if [ -n "$1" ]; then
> +        	for (( i=0; i<${#1}; ++i )); do
> +	            local char=${1:$i:1}
> +            	WORDBREAKS=${WORDBREAKS//$char/}
> +        	done
> +    	fi
> +    	local cur=${COMP_LINE:0:$COMP_POINT}
> +    	local tmp=$cur
> +    	local word_start=`expr "$tmp" : '.*['"$WORDBREAKS"']'`
> +    	while [ "$word_start" -ge 2 ]; do
> +	        # Get character before $word_start
> +        	local char=${cur:$(( $word_start - 2 )):1}
> +        	# If the WORDBREAK character isn't escaped, exit loop
> +        	if [ "$char" != "\\" ]; then
> +	            break
> +        	fi
> +        	# The WORDBREAK character is escaped;
> +        	# Recalculate $word_start
> +        	tmp=${COMP_LINE:0:$(( $word_start - 2 ))}
> +        	word_start=`expr "$tmp" : '.*['"$WORDBREAKS"']'`
> +    	done
> +
> +	    cur=${cur:$word_start}
> +	    printf "%s" "$cur"
> +	} # __get_cword4()
> +fi
> +
> @@ -551,7 +698,7 @@ __git_complete_revlist ()
>  __git_complete_remote_or_refspec ()
>  {
>  	local cmd="${COMP_WORDS[1]}"
> -	local cur="${COMP_WORDS[COMP_CWORD]}"
> +	local cur=`_get_cword ":"`
>  	local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
>  	while [ $c -lt $COMP_CWORD ]; do
>  		i="${COMP_WORDS[c]}"
> @@ -1360,7 +1508,7 @@ _git_log ()
>  {
>  	__git_has_doubledash && return
>  
> -	local cur="${COMP_WORDS[COMP_CWORD]}"
> +	local cur=`_get_cword "="`
>  	local g="$(git rev-parse --git-dir 2>/dev/null)"
>  	local merge=""
>  	if [ -f "$g/MERGE_HEAD" ]; then
> @@ -1419,7 +1567,7 @@ _git_merge ()
>  {
>  	__git_complete_strategy && return
>  
> -	local cur="${COMP_WORDS[COMP_CWORD]}"
> +	local cur=`_get_cword`
>  	case "$cur" in
>  	--*)
>  		__gitcomp "$__git_merge_options"
> 
> 
> I just need someone to test the new script on Bash 3. If somebody is
> willing to test, drop me an private email and I can send the new script.
> 

Re: [completion] Request: Include remote heads as push targets

[Peter van der Does]

On Sun, 24 Oct 2010 13:23:26 +0200
SZEDER Gábor <szeder@ira.uka.de> wrote:


> Checking for the function first, and declaring it if it doesn't exists
> could be a viewable alternative, but not with _get_cword().  The
> _get_cword() implementation you are adding below is outdated.  It is
> from bash-completion 1.1, changed quite a bit after that, and in the
> end became deprecated in 1.2 in favor of _get_comp_words_by_ref().
> 
> 

Ok, I just used the bash_completion version installed with Ubuntu Lucid.
I think we should use the 1.2 version.

-- 
Peter van der Does

GPG key: E77E8E98

IRC: Ganseki on irc.freenode.net
Twitter: @petervanderdoes

WordPress Plugin Developer
Blog: http://blog.avirtualhome.com
Forums: http://forums.avirtualhome.com
Twitter: @avhsoftware