*** BLURB HERE ***
Make git-completion Bash 4 compatible.

I've made the following changes since v3:
- Patch is based upon the next branch.
- Grammatical error in commit message

Peter van der Does (2):
  Introduce functions from bash-completion project.
  Use the new functions to get the current cword.

 contrib/completion/git-completion.bash |  446 ++++++++++++++++++++++++++------
 1 files changed, 363 insertions(+), 83 deletions(-)

-- 
1.7.3.2

--

[ message continues ]

Change the completion functions to use the newly introduced functions to
get the current and/or previous cword and to reassemble the COMP_CWORDS,
making sure the options are correctly split.

Signed-off-by: Peter van der Does <peter@avirtualhome.com>
---
 contrib/completion/git-completion.bash |  223 ++++++++++++++++++++------------
 1 files changed, 140 insertions(+), 83 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0036e8b..f915e1f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -554,7 +554,8 @@ __gitcomp_1 ()
 # generates completion reply with compgen
 __gitcomp ()
 {
-	local cur="${COMP_WORDS[COMP_CWORD]}"
+	local cur
+	_get_comp_words_by_ref -n "=" cur
 	if [ $# -gt 2 ]; then
 		cur="$3"
 	fi
@@ -615,7 +616,8 @@ __git_tags ()
 __git_refs ()
 {
 	local i is_hash=y dir="$(__gitdir "${1-}")" track="${2-}"
-	local cur="${COMP_WORDS[COMP_CWORD]}" format refs
+	local cur format refs
+	_get_comp_words_by_ref cur
 	if [ -d "$dir" ]; then
 		case "$cur" in
 		refs|refs/*)
@@ -729,7 +731,8 @@ __git_compute_merge_strategies ()
 
 __git_complete_file ()
 {
-	local pfx ls ref cur="${COMP_WORDS[COMP_CWORD]}"
+	local pfx ls ref cur
+	_get_comp_words_by_ref -n ":" cur
 	case "$cur" in
 	?*:*)
 		ref="${cur%%:*}"
@@ -777,7 +780,8 @@ __git_complete_file ()
 
 __git_complete_revlist ()
 {
-	local pfx cur="${COMP_WORDS[COMP_CWORD]}"
+	local pfx cur
+	_get_comp_words_by_ref cur
 	case "$cur" in
 	*...*)
 		pfx="${cur%...*}..."
@@ -797,11 +801,13 @@ __git_complete_revlist ()
 
 __git_complete_remote_or_refspec ()
 {
-	local cmd="${COMP_WORDS[1]}"
-	local cur="${COMP_WORDS[COMP_CWORD]}"
+	local cur words cword
+	_get_comp_words_by_ref -n ":" cur words cword
+	local cmd="${words[1]}"
 	local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
-	while [ $c -lt $COMP_CWORD ]; do
-		i="${COMP_WORDS[c]}"
+
+	while [ $c -lt $cword ]; ...
[ message continues ]

Hi Peter,


Some comments.  Please don't reroll until discussion has quieted down
(though thoughts and incremental patches would always be welcome, of

To save the reader some time: this excludes '=' from word-breaking
characters, so $cur will include an = when appropriate.  IIUC that is
precisely the behavior that bash 4 changed.

Perhaps that is worth explaining in the commit message in the next

This does not exclude '=' from word-breaking characters.  Would that
break completion of

	git update-ref refs/topics/foo=bar HEAD
	git checkout refs/topics/foo=<tab><tab>


This treats '=' as a word-breaking character but not ':'.  Is that






':' and '=' are word-breakers when looking for "--".

[etc]

So in general, it seems that : and = are treated as word-breakers
after this change much more often than git itself would treat them
as such.  Is that intentional?  What rule is used to choose -n
arguments?
--

[ message continues ]

Hi,


Here are my nits I mentioned yesterday.



... that should be $cword in the condition, without the s at the end.
These two typos caused some weird behaviors when completing long
options for commands understanding the '--' option-path separator,


These three changes have nothing to do with bash4 issues, and they
break in 'set -u' environments, because $ZSH_VERSION is, of course,
undefined in bash.


Best,
Gábor

--

[ message continues ]

The completion script does not work as expected under Bash 4.
Bash: 3
output:
$ git log --pretty=<tab><tab>
email     full      medium    raw
format:   fuller    oneline   short

Bash: 4
output:
$ git log --pretty=<tab><tab>
.bash_logout         .local/
.bash_profile        Music/
--More--

With Bash 4 the way word breaking is done in the programmable completion
code has changed. The documentation at the bash project is not very
clear what was changed, the only reference found is in the NEWS section:

i.  The programmable completion code now uses the same set of characters
as readline when breaking the command line into a list of words.

The word breaking problem occurs with certain characters, like colon and
equal sign.

The bash-completion project (http://bash-completion.alioth.debian.org/)
has written several functions to overcome this problem. By using these
functions within the git-completion.bash script the word breaking
problem is solved.

Signed-off-by: Peter van der Does <peter@avirtualhome.com>
---
 contrib/completion/git-completion.bash |  223 ++++++++++++++++++++++++++++++++
 1 files changed, 223 insertions(+), 0 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index f710469..0036e8b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -82,6 +82,229 @@ case "$COMP_WORDBREAKS" in
 *)   COMP_WORDBREAKS="$COMP_WORDBREAKS:"
 esac
 
+# If the function _get_comp_words_by_ref does not exists, we can assume the
+# bash_completion 1.2 script isn't loaded and therefor we're defining the
+# necessary functions ourselves.
+# The functions come from the bash_completion 1.2 script.
+# See: http://bash-completion.alioth.debian.org/
+if ! type _get_comp_words_by_ref &> /dev/null ; then
+	# The bash_completion 1.2 library wasn't loaded,
+	# we have to define some functions from it ourselves.
+
+	# Assign variables one scope above the caller
+	# Usage: local ...
[ message continues ]

Please don't do that.  Documentation/SubmittingPatches explains

Thanks, I'll look over this version then.
--

[ message continues ]

Hi,


I have a few little changes to fix some minor nits and bugs.  Will try
to find some time tomorrow to dig them up and send them to the list.


Best,
Gábor

--

[ message continues ]

Hi again,



This patch introduces a minor regression in that it breaks the
(already somewhat incomplete) zsh support.  Should be fixable by

This one introduces some subtle differences between commands and imho
does more than it set out to do, by differentiating word splitting
behavior between commands.  bash 3 was not splitting COMP_WORDS at
equal signs or colons, ever.  Maybe we can start with that and then
make refinements on top later.

While trying that out, I had an idea.  The patch depends on
understanding the bash-completion library function introduced by patch
1, but I think we can avoid that by rearranging the patch series like
this:

 1. If _get_comp_words_by_ref is already defined, use it to fetch
    completion words.  Otherwise, just use COMP_WORDS (using a stub
    _get_comp_words_by_ref), maintaining the current behavior.
    [shown below]

 2. Import the definition of _get_comp_words_by_ref from the
    bash-completion lib and use it if ZSH_VERSION is unset.

 3. Further refinements, if needed.

What do you think?

-- 8< --
From: Peter van der Does <peter@avirtualhome.com>
Subject: bash: work around bash 4.0 change in COMP_WORDS semantics

Before bash 4, running

	$ git log --pretty=m <tab><tab>

would give a list of pretty formats starting with 'm', but now it
completes on ordinary files instead.  It seems that as part of a
rework of completion word splitting, bash 4.0 changed the semantics of
the COMP_WORDS array: previously, --pretty=m was treated as one word,
but now it breaks on '=' if COMP_WORDBREAKS contains an equal sign.

It would be possible to work around that by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), doing
so is likely to break *other* completion scripts.  Luckily, the
bash-completion library includes a better workaround --- a
_get_comp_words_by_ref function to retrieve an array somewhat like
COMP_WORDS but:

 * ...
[ message continues ]

On Thu, 2 Dec 2010 03:16:24 -0600

I like the idea and we should go with this solution.

If by importing you mean using :
[CODE]. /git_bash_completion-functions[/CODE] in the
contrib/completion/git-completion.bash script, which would be the best
solution imho. The question is where to place that the function file.

This would also means changing the documentation inside the
git-completion.bash script, currently the instructions are:
[QUOTE]
# To use these routines:
#
#    1) Copy this file to somewhere (e.g. ~/.git-completion.sh).
#    2) Added the following line to your .bashrc:
#        source ~/.git-completion.sh
[/QUOTE]

It would have to include copying the functions file somewhere as well.

Or we could use the method used now and include the functions in the
git-completion.bash script.

I'll be waiting for further feedback from Gábor, as he mentioned on the
list of he had some little changes to fix some minor nits and bugs
before completely implementing this solution.

-- 
Peter van der Does

GPG key: E77E8E98

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

--

[ message continues ]

Add a minimal implementation of _get_comp_words_by_ref,
the routine used to work around bash 4.0's COMP_WORDS semantics.

Based on bash-completion 2.x (commit bf763033, 2010-10-26) but
tweaked for simplicity and to allow zsh to at least parse the
code.

Based-on-patch-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---

Sorry for the lack of clarity.  Here's what I meant.

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

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b0eb45..1743319 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -327,7 +327,102 @@ __gitcomp_1 ()
 	done
 }
 
+# The following function is based on code from:
+#
+#   bash_completion - programmable completion functions for bash 3.2+
+#
+#   Copyright © 2006-2008, Ian Macdonald <ian@caliban.org>
+#             © 2009-2010, Bash Completion Maintainers
+#                     <bash-completion-devel@lists.alioth.debian.org>
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2, or (at your option)
+#   any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program; if not, write to the Free Software Foundation,
+#   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+#   The latest version of this software can be obtained here:
+#
+#   http://bash-completion.alioth.debian.org/
+#
+#   RELEASE: ...
[ message continues ]

Hi,



Some extension:

Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line.  In Bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page).  This behavior has changed with Bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).

Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in Bash also affects git's completion script.  For
example, when using Bash v4 the completion script can't provide
possible options for a command line argument (e.g. git log
--pretty=<TAB><TAB> lists files, but it should list possible log
formats).


I would really, _really_ like to have the above text in the commit
message (either in yours or in Peter's), because it took me weeks to
figure this out ;)  Not that it was that difficult, but when I
discovered this issue more than a month ago, "unfortunately" I
remembered a similar issue (db8a9ff, bash completion: Resolve git show
ref:path<tab> losing ref: portion, 2008-07-15), and it got me
sidetracked really really  badly.

(I'm still wondering what Bash v3.x was doing with COMP_WORDBREAKS,

I haven't tried to understand the code yet, but noticed the following


This should be ${ZSH_VERSION-} to keep 'set -u' environments happy.

 
--

[ message continues ]

Based on v1.5.6.4~9^2 (bash completion: Resolve git show ref:path<tab>
losing ref: portion, 2008-07-15) it seems COMP_WORDBREAKS determined
the interpretation of COMPREPLY (result of completion).  Of course it

Nice catches; thanks.
--

[ message continues ]

I reported this issue over a year ago!

http://article.gmane.org/gmane.comp.version-control.git/133067

I'll be glad to see it fixed (but I haven't had time to look over these
patches and try them out yet).
--

[ message continues ]

Hi Jonathan,

What is this patch based on?


Thanks,
Gábor


--

[ message continues ]

Ah, sorry, applies to d93f4a297 (bash: work around bash 4.0 change in
COMP_WORDS semantics, 2010-12-02).

Can re-send in a few moments based on maint if you'd like.
--

[ message continues ]

Hi Jonathan,



In which repo? ;)

I don't have d93f4a297, but I have e0a9590 (Introduce functions from
bash-completion project., 2010-12-01) and c7e75bb (Use the new
functions to get the current cword., 2010-12-01) instead, which were
merged into pu at 0c30752 (Merge branch 'pd/bash-4-completion' into
pu, 2010-12-03).

Hm, waittaminit...  Ah, OK, nevermind, got it.  There was a patch in

  http://article.gmane.org/gmane.comp.version-control.git/162686

I forgot to apply first...  Now I have it all, seems to work so far.


Thanks,
Gábor

--

[ message continues ]

Thanks.  I had meant to say that patch 1 applies to 06f44c3c
(completion: make compatible with zsh, 2010-09-06) and that the bash 4
support could be rebased to work without that if there is demand.

*goes off to get some coffee*

Sorry for the confusion.
Jonathan
--

[ message continues ]

Sorry, but whose repository does that object live in?
--

[ message continues ]

Agh, sorry for the mess.  Please fetch

  git://repo.or.cz/git/jrn.git pd/bash-4-completion 

to receive the following history:

  o [maint-1.7.2] --- A --- B --- M [FETCH_HEAD]
                                 /
                                o [master (early part)]

[A] bash: get --pretty=m<tab> completion to work with bash v4
(by Peter)

[B] bash: simple reimplementation of _get_comp_words_by_ref
(discussed above)

[M] Merge branch 'master' (early part) into pd/bash-4-completion
(zsh compatibility)

[master (early part)] completion: fix zsh check under bash with 'set -u'
(2010-10-28 11:45:00 -0700).

A and B are the patches sent previously in this thread, rebased on an
older code base to avoid the zsh support.  A combined diff for the
merge 'M' will follow.  Thoughts, suggestions, acks, test reports
would be welcome.

Thanks for your patience.
Jonathan
--

[ message continues ]

From: Peter van der Does <peter@avirtualhome.com>

Bash's programmable completion provides the COMP_WORDS array variable,
which holds the individual words in the current command line.  In bash
versions prior to v4 "words are split on shell metacharacters as the
shell parser would separate them" (quote from bash v3.2.48's man
page).  This behavior has changed with bash v4, and the command line
"is split into words as readline would split it, using COMP_WORDBREAKS
as" "the set of characters that the readline library treats as word
separators" (quote from bash v4's man page).

Since COMP_WORDBREAKS contains the characters : and = by default, this
behavior change in bash affects git's completion script.  For example,
before bash 4, running

	$ git log --pretty=m <tab><tab>

would give a list of pretty-printing formats starting with 'm' but now
it completes on branch names.

It would be possible to work around this by removing '=' and ':' from
COMP_WORDBREAKS, but as noticed in v1.5.6.4~9^2 (bash completion:
Resolve git show ref:path<tab> losing ref: portion, 2008-07-15), that
would break *other* completion scripts.  The bash-completion library
includes a better workaround: the _get_comp_words_by_ref function
re-assembles a copy of COMP_WORDS, excluding a collection of word
separators of the caller's choice.  Use it.

As a bonus, this improves behavior when tab is pressed with the cursor
in the middle of a word if the bash-completion lib is loaded.

To avoid breaking setups with the bash-completion library not already
loaded, if the _get_comp_words_by_ref function is not defined then use
a shim that just reads COMP_WORDS instead (no change from the current
behavior in that case).

Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Explained-by: SZEDER Gábor <szeder@ira.uka.de>
---
 contrib/completion/git-completion.bash |  236 +++++++++++++++++++++----------
 1 files changed, 160 insertions(+), 76 ...
[ message continues ]

Add a minimal implementation of _get_comp_words_by_ref so

	$ git show head:g <tab><tab>

on bash 4 can complete paths within the head commit without requiring
the bash_completion functions to be loaded.  This is a follow-up to
the previous patch (bash: get --pretty=m<tab> completion to work with
bash v4).

Based on bash-completion 2.x (commit bf763033, 2010-10-26) but tweaked
for simplicity and to allow zsh to parse the code.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: SZEDER Gábor <szeder@ira.uka.de>
---
 contrib/completion/git-completion.bash |  118 +++++++++++++++++++++++++++++--
 1 files changed, 110 insertions(+), 8 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 68b68d0..1747091 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -321,26 +321,128 @@ __gitcomp_1 ()
 	done
 }
 
+# The following function is based on code from:
+#
+#   bash_completion - programmable completion functions for bash 3.2+
+#
+#   Copyright © 2006-2008, Ian Macdonald <ian@caliban.org>
+#             © 2009-2010, Bash Completion Maintainers
+#                     <bash-completion-devel@lists.alioth.debian.org>
+#
+#   This program is free software; you can redistribute it and/or modify
+#   it under the terms of the GNU General Public License as published by
+#   the Free Software Foundation; either version 2, or (at your option)
+#   any later version.
+#
+#   This program is distributed in the hope that it will be useful,
+#   but WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#   GNU General Public License for more details.
+#
+#   You should have received a copy of the GNU General Public License
+#   along with this program; if not, write to the Free Software Foundation,
+#   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+#   The latest version of ...
[ message continues ]

* 'master' (early part): (529 commits)
  completion: fix zsh check under bash with 'set -u'
  Fix copy-pasted comments related to tree diff handling.
  Git 1.7.3.2
  {cvs,svn}import: use the new 'git read-tree --empty'
  t/t9001-send-email.sh: fix stderr redirection in 'Invalid In-Reply-To'
  Clarify and extend the "git diff" format documentation
  git-show-ref.txt: clarify the pattern matching
  documentation: git-config minor cleanups
  Update test script annotate-tests.sh to handle missing/extra authors
  ...

Conflicts:
	GIT-VERSION-GEN
	RelNotes
	contrib/completion/git-completion.bash
---
Suggestions for further work:

 - check edge cases:

	git log --pretty m<tab><tab>		should complete formats
	git log --pretty =<tab><tab>		should complain
	git log --pretty= m<tab><tab>		should complete commits

 - use a custom function to avoid repeating

	_get_comp_words_by_ref -n =:

   As an application, consider teaching git to complete

	git show HEAD@{<tab><tab>		completes to numbers and "upstream"

   Would the argument to -n need an @ for that?

 - get the zsh completion to actually work. :)  Even without this
   series, it seems it is willing to complete subcommand names and
   switches for git but nothing more.

 - adopt the rest of bash_completion's _get_comp_words_by_ref logic,
   so

	git log --pretty=m<cursor>master <tab><tab>

   completes formats starting with 'm', not formats starting with 'mmaster'.

If something turned out buggy, I'd be glad to fix it, but aside from
that I probably will not be working much more on this topic.  (Perhaps
an actual tab completion user would have a better sense of which
aspects are worth working on.)  Please feel free to pick it up and run
in whatever direction you please.

Good night,
Jonathan

diff --cc contrib/completion/git-completion.bash
index 1747091,168669b..d117055
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@@ -321,135 -327,6 +327,162 @@@ __gitcomp_1 (
  ...
[ message continues ]