[PATCH v3] git-completion.bash: add support for path completion

[PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

The git-completion.bash script did not implemented full, git aware,
support for completion, for git commands that operate on files within
the current working directory or the index.

For these commands, only long options completion was available.
As an example:

	git add <TAB>

will suggest all files in the current working directory, including
ignored files and files that have not been modified.

Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths within the current
working directory or the index, as the follow:

* the path completion for the "git mv", "git rm" and "git ls-tree"
  commands will suggest all cached files.

* the path completion for the "git add" command will suggest all
  untracked and modified files.  Ignored files are excluded.

* the path completion for the "git clean" command will suggest all
  untracked files.  Ignored files are excluded.

* the path completion for the "git commit" command will suggest all
  files that have been modified from the HEAD.

For all affected commands, completion will always stop at directory
boundary.  Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.

Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
---
 contrib/completion/git-completion.bash | 112 ++++++++++++++++++++++++++++-----
 1 file changed, 97 insertions(+), 15 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b77eb1..923ef37 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
 #    *) .git/remotes file names
 #    *) git 'subcommands'
 #    *) tree paths within 'ref:path/to/file' expressions
+#    *) file paths within current working directory and index
 #    *) common --long-options
 #
 # To use these routines:
@@ -233,6 +234,59 @@ __gitcomp_nl ()
 	COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
 }
 
+# Perl filter used to process path list returned by ls-files and
+# diff-index --name-only commands, in order to list file names
+# relative to a specified directory, and append a slash to directory
+# names.
+# The script expects the prefix path in the "pfx" environ variable.
+# The output must be processed with the uniq filter, to remove
+# duplicate directories.
+# XXX remove duplicates in the Perl script ?
+__git_index_file_list_filter='$pfx = $ENV{"pfx"};
+			$idx = index($_, $pfx);
+			if ($idx == 0) {
+				$_ = substr $_, length($pfx);
+				@segments = split("/", $_);
+				if ($segments[1]) {
+					print $segments[0], "/\n"
+				} else {
+					print $segments[0], "\n"
+				}
+			}'
+
+# __git_files accepts 1 or 2 arguments:
+# 1: A string for file index status mode ("c", "m", "d", "o"), as
+#    supported by git ls-files command.  This is required.
+# 2: An optional directory path.  If provided, only files within the
+#    specified directory are listed.  Sub directories are never recursed.
+#    Path must have a trailing slash.
+__git_files ()
+{
+	local dir="$(__gitdir)" flags="-${1}"
+
+	if [ -d "$dir" ]; then
+		git --git-dir="$dir" ls-files --exclude-standard ${flags} ${pfx} \
+			| pfx=$2 perl -ne "${__git_index_file_list_filter}" \
+			| uniq
+		return
+	fi
+}
+
+# __git_commit_files accepts 1 optional argument: a directory path.
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed.  Path must have a trailing slash.
+__git_commit_files ()
+{
+	local dir="$(__gitdir)"
+
+	if [ -d "$dir" ]; then
+		git --git-dir="$dir" diff-index --name-only HEAD \
+			| pfx=$1 perl -ne "${__git_index_file_list_filter}" \
+			| uniq
+		return
+	fi
+}
+
 __git_heads ()
 {
 	local dir="$(__gitdir)"
@@ -430,6 +484,25 @@ __git_complete_revlist_file ()
 }
 
 
+# __git_complete_index_file requires 1 argument, the file index
+# status mode
+_git_complete_index_file ()
+{
+	local pfx cur_="$cur" flags=${1}
+	case "$cur_" in
+		?*/*)
+			pfx="${cur_%/*}"
+			cur_="${cur_##*/}"
+			pfx="${pfx}/"
+
+			__gitcomp_nl "$(__git_files ${flags} ${pfx})" "$pfx" "$cur_" ""
+			;;
+		*)
+			__gitcomp_nl "$(__git_files ${flags})" "" "$cur_" ""
+			;;
+	esac
+}
+
 __git_complete_file ()
 {
 	__git_complete_revlist_file
@@ -770,8 +843,6 @@ _git_apply ()
 
 _git_add ()
 {
-	__git_has_doubledash && return
-
 	case "$cur" in
 	--*)
 		__gitcomp "
@@ -780,7 +851,8 @@ _git_add ()
 			"
 		return
 	esac
-	COMPREPLY=()
+	# XXX should we check for --update and --all options ?
+	_git_complete_index_file "om"
 }
 
 _git_archive ()
@@ -930,15 +1002,14 @@ _git_cherry_pick ()
 
 _git_clean ()
 {
-	__git_has_doubledash && return
-
 	case "$cur" in
 	--*)
 		__gitcomp "--dry-run --quiet"
 		return
 		;;
 	esac
-	COMPREPLY=()
+	# XXX should we check for -x option ?
+	_git_complete_index_file "o"
 }
 
 _git_clone ()
@@ -969,7 +1040,7 @@ _git_clone ()
 
 _git_commit ()
 {
-	__git_has_doubledash && return
+	local pfx cur_=${cur}
 
 	case "$cur" in
 	--cleanup=*)
@@ -997,8 +1068,20 @@ _git_commit ()
 			--verbose --quiet --fixup= --squash=
 			"
 		return
+		;;
+	?*/*)
+		pfx="${cur_%/*}"
+		cur_="${cur_##*/}"
+		pfx="${pfx}/"
+
+		__gitcomp_nl "$(__git_commit_files ${pfx})" "$pfx" "$cur_" ""
+		return
+		;;
+	*)
+		__gitcomp_nl "$(__git_commit_files)" "" "$cur_" ""
+		return
+		;;
 	esac
-	COMPREPLY=()
 }
 
 _git_describe ()
@@ -1216,8 +1299,6 @@ _git_init ()
 
 _git_ls_files ()
 {
-	__git_has_doubledash && return
-
 	case "$cur" in
 	--*)
 		__gitcomp "--cached --deleted --modified --others --ignored
@@ -1230,7 +1311,9 @@ _git_ls_files ()
 		return
 		;;
 	esac
-	COMPREPLY=()
+	# XXX ignore options like --modified and always suggest all cached
+	# files.
+	_git_complete_index_file "c"
 }
 
 _git_ls_remote ()
@@ -1362,7 +1445,8 @@ _git_mv ()
 		return
 		;;
 	esac
-	COMPREPLY=()
+	# XXX needs more work
+	_git_complete_index_file "c"
 }
 
 _git_name_rev ()
@@ -2068,15 +2152,13 @@ _git_revert ()
 
 _git_rm ()
 {
-	__git_has_doubledash && return
-
 	case "$cur" in
 	--*)
 		__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
 		return
 		;;
 	esac
-	COMPREPLY=()
+	_git_complete_index_file "c"
 }
 
 _git_shortlog ()
-- 
1.8.1.rc1.18.g9db0d25

Re: [PATCH v3] git-completion.bash: add support for path completion

[Junio C Hamano]

[jch: cc'ed git-completion experts to review implementation details]

Manlio Perillo <manlio.perillo@gmail.com> writes:

> The git-completion.bash script did not implemented full, git aware,
> support for completion, for git commands that operate on files within
> the current working directory or the index.
>
> For these commands, only long options completion was available.

I find the "long options completion" is a misleading phrase.  It
sounds as if you changed the current completion that does not
complete "git commit -<TAB>" but does "git commit --<TAB>" to
complete the short options (e.g. "git commit -c"), but I do not
think that is the topic of this patch.

> As an example:
>
> 	git add <TAB>
>
> will suggest all files in the current working directory, including
> ignored files and files that have not been modified.
>
> Full support for completion is now implemented, for git commands where

s/Full.*implemented/Support more comprehensive completion/; or
something, talking in the imperative mood (i.e. as if you are giving
the order to the codebase to do something).

> the non-option arguments always refer to paths within the current
> working directory or the index, as the follow:
>
> * the path completion for the "git mv", "git rm" and "git ls-tree"
>   commands will suggest all cached files.

I thought you dropped "git mv" in this round.

> * the path completion for the "git add" command will suggest all
>   untracked and modified files.  Ignored files are excluded.
>
> * the path completion for the "git clean" command will suggest all
>   untracked files.  Ignored files are excluded.
>
> * the path completion for the "git commit" command will suggest all
>   files that have been modified from the HEAD.
>
> For all affected commands, completion will always stop at directory
> boundary.  Only standard ignored files are excluded, using the
> --exclude-standard option of the ls-files command.

I read "always stop at directory boundary" to mean that

	git cmd t<TAB>

will give us "t/ tag.c" (assuming there is a new or modified file in
t/ and tag.c is the only modified file at the root level that begins
with "t") and then

	git cmd t/<TAB>

will likewise show the files and top-level subdirectories within t/
directory.  That would be great.

> Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
> ---
>  contrib/completion/git-completion.bash | 112 ++++++++++++++++++++++++++++-----
>  1 file changed, 97 insertions(+), 15 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 0b77eb1..923ef37 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -13,6 +13,7 @@
>  #    *) .git/remotes file names
>  #    *) git 'subcommands'
>  #    *) tree paths within 'ref:path/to/file' expressions
> +#    *) file paths within current working directory and index
>  #    *) common --long-options
>  #
>  # To use these routines:
> @@ -233,6 +234,59 @@ __gitcomp_nl ()
>  	COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
>  }
>  
> +# Perl filter used to process path list returned by ls-files and
> +# diff-index --name-only commands, in order to list file names
> +# relative to a specified directory, and append a slash to directory
> +# names.
> +# The script expects the prefix path in the "pfx" environ variable.
> +# The output must be processed with the uniq filter, to remove
> +# duplicate directories.
> +# XXX remove duplicates in the Perl script ?

Surely, that will remove one fork/exec with pipeline.  I am not sure
what the performance implication of using Perl here, but because we
do not have to stick to POSIX shell in this file, the completion
experts would be able to help rewriting this logic as a pure bash
script.

> +__git_index_file_list_filter='$pfx = $ENV{"pfx"};
> +			$idx = index($_, $pfx);
> +			if ($idx == 0) {
> +				$_ = substr $_, length($pfx);
> +				@segments = split("/", $_);
> +				if ($segments[1]) {
> +					print $segments[0], "/\n"
> +				} else {
> +					print $segments[0], "\n"
> +				}
> +			}'
> +
> +# __git_files accepts 1 or 2 arguments:
> +# 1: A string for file index status mode ("c", "m", "d", "o"), as
> +#    supported by git ls-files command.  This is required.
> +# 2: An optional directory path.  If provided, only files within the
> +#    specified directory are listed.  Sub directories are never recursed.
> +#    Path must have a trailing slash.
> +__git_files ()
> +{
> +	local dir="$(__gitdir)" flags="-${1}"
> +
> +	if [ -d "$dir" ]; then
> +		git --git-dir="$dir" ls-files --exclude-standard ${flags} ${pfx} \
> +			| pfx=$2 perl -ne "${__git_index_file_list_filter}" \
> +			| uniq

This is purely a style thing (note that style suggestions are not
optional), but

        the data source command |
        a filter command |
        another filter command

is easier to read and can be spelled without the backslash.  The
same comment applies to git-commit-files as well.

Thanks.

Re: [PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 18/12/2012 18:53, Junio C Hamano ha scritto:
> [jch: cc'ed git-completion experts to review implementation details]
> 
> Manlio Perillo <manlio.perillo@gmail.com> writes:
> 
>> The git-completion.bash script did not implemented full, git aware,
>> support for completion, for git commands that operate on files within
>> the current working directory or the index.
>>
>> For these commands, only long options completion was available.
> 
> I find the "long options completion" is a misleading phrase.  It
> sounds as if you changed the current completion that does not
> complete "git commit -<TAB>" but does "git commit --<TAB>" to
> complete the short options (e.g. "git commit -c"), but I do not
> think that is the topic of this patch.
> 

It does not sound misleading to me.
I'm saying that the git-completion.bash script only implemented
completion for long options, but not for file names in the current
working directory.

Do you think I should rewrite the subject and the log message introduction?

As an example, something like this in the subject:

  git-completion.bash: improve some git commands completion

and in the message:

  The git-completion.bash script did not implemented full, git aware,
  support for completion, for git commands that operate on files within
  the current working directory or the index.

  As an example:

 ...

I'm still not fully satisfied with it, however.
It still requires reading the full message to understand the changes
implemented.

>> As an example:
>>
>> 	git add <TAB>
>>
>> will suggest all files in the current working directory, including
>> ignored files and files that have not been modified.
>>
>> Full support for completion is now implemented, for git commands where
> 
> s/Full.*implemented/Support more comprehensive completion/; or
> something, talking in the imperative mood (i.e. as if you are giving
> the order to the codebase to do something).
> 

Ok.

>> the non-option arguments always refer to paths within the current
>> working directory or the index, as the follow:
>>
>> * the path completion for the "git mv", "git rm" and "git ls-tree"
>>   commands will suggest all cached files.
> 
> I thought you dropped "git mv" in this round.
> 

Well, no.
But the current implementation should not cause problems.
Also note that I added support for ls-files, too.

There are some XXX marks in the code, but I think that the changes
always improve the old behaviour.

> [...]
>> For all affected commands, completion will always stop at directory
>> boundary.  Only standard ignored files are excluded, using the
>> --exclude-standard option of the ls-files command.
> 
> I read "always stop at directory boundary" to mean that
> 
> 	git cmd t<TAB>
> 
> will give us "t/ tag.c" (assuming there is a new or modified file in
> t/ and tag.c is the only modified file at the root level that begins
> with "t") and then
> 
> 	git cmd t/<TAB>
> 
> will likewise show the files and top-level subdirectories within t/
> directory.  That would be great.
> 

Yes, this is how it works, bugs excluded (I'm not a bash/perl expert).


> [...]
>> +# Perl filter used to process path list returned by ls-files and
>> +# diff-index --name-only commands, in order to list file names
>> +# relative to a specified directory, and append a slash to directory
>> +# names.
>> +# The script expects the prefix path in the "pfx" environ variable.
>> +# The output must be processed with the uniq filter, to remove
>> +# duplicate directories.
>> +# XXX remove duplicates in the Perl script ?
> 
> Surely, that will remove one fork/exec with pipeline.  I am not sure
> what the performance implication of using Perl here, but because we
> do not have to stick to POSIX shell in this file, the completion
> experts would be able to help rewriting this logic as a pure bash
> script.
> 

Ok. I'll wait for a review from git-completion experts.

Note that the performance is the reason why I suggested, in a previous
email, that git should have some more options to format data in custom ways.
As an example, there is no way to tell ls-files to not recurse
directories, and there is no way to also get the file type.

A --no-recurse option, and a change in the code to make, as an example

  git ls-files --stage --modified

to honor the --modified option,  will probably make it possible to use a
simple sed filter (there is still the problem that, unlike ls-tree,
ls-files shows the complete file path).

> [...]
>> +__git_files ()
>> +{
>> +	local dir="$(__gitdir)" flags="-${1}"
>> +
>> +	if [ -d "$dir" ]; then
>> +		git --git-dir="$dir" ls-files --exclude-standard ${flags} ${pfx} \
>> +			| pfx=$2 perl -ne "${__git_index_file_list_filter}" \
>> +			| uniq
> 
> This is purely a style thing (note that style suggestions are not
> optional), but
> 
>         the data source command |
>         a filter command |
>         another filter command
> 
> is easier to read and can be spelled without the backslash.  The
> same comment applies to git-commit-files as well.
> 

I agree.

But I was copying the style currently used in the script
(see the __git_complete_revlist_file function).

Note that I plan to do a small code refactorization, since I need the
ls-tree support code from __git_complete_revlist_file function for a
future change. I can fix these style issues in that patch.

I plan to improve completion support for checkout and reset commands,
too (currently only the commit/tree-ish argument is autocompleted, but
not the path).


Regards  Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDQvDIACgkQscQJ24LbaUTT9wCgh6jtbhdQ7GNIkqCq34QjXdIs
w9QAnjz2VjPFm4n2ICkcWWEsqWDWM+Hm
=8/Ad
-----END PGP SIGNATURE-----

Re: [PATCH v3] git-completion.bash: add support for path completion

[Junio C Hamano]

Manlio Perillo <manlio.perillo@gmail.com> writes:

> Il 18/12/2012 18:53, Junio C Hamano ha scritto:
>> [jch: cc'ed git-completion experts to review implementation details]
>> 
>> Manlio Perillo <manlio.perillo@gmail.com> writes:
>> 
>>> The git-completion.bash script did not implemented full, git aware,
>>> support for completion, for git commands that operate on files within
>>> the current working directory or the index.
>>>
>>> For these commands, only long options completion was available.
>> 
>> I find the "long options completion" is a misleading phrase.  It
>> sounds as if you changed the current completion that does not
>> complete "git commit -<TAB>" but does "git commit --<TAB>" to
>> complete the short options (e.g. "git commit -c"), but I do not
>> think that is the topic of this patch.
>> 
>
> It does not sound misleading to me.
> I'm saying that the git-completion.bash script only implemented
> completion for long options, but not for file names in the current
> working directory.
>
> Do you think I should rewrite the subject and the log message introduction?

The subject sounds fine; it is just "It only does long options"
sounded as if it were viewing the lack of "short options" support as
an issue.  In other words, my knee-jerk answer to "long options, as
opposed to what???" question was "short options", not "files".

If the phrase were "It only does options", the question would become
"options as opposed to what???", which may have given me a chance to
guess "files" as the answer to that question.

> As an example, something like this in the subject:
>
>   git-completion.bash: improve some git commands completion

I think the original is better; you do not touch any "options",
either long or short.  You are improving "paths", and the original
is much clearer on that point.

>
> and in the message:
>
>   The git-completion.bash script did not implemented full, git aware,
>   support for completion, for git commands that operate on files within

With s/for completion/to complete paths/, it would be perfect.  You
do not touch options, and this new log message does not talk about
it.  Much nicer than the one that was posted.

> Note that the performance is the reason why I suggested, in a previous
> email, that git should have some more options to format data in custom ways.
> As an example, there is no way to tell ls-files to not recurse
> directories, and there is no way to also get the file type.

To ls-files, no-recurse is an idiotic thing to ask.  The index is a
flat structure that is read as a whole.  There is no recursion
involved.

Re: [PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 18/12/2012 20:22, Junio C Hamano ha scritto:
> [...]
>> Note that the performance is the reason why I suggested, in a previous
>> email, that git should have some more options to format data in custom ways.
>> As an example, there is no way to tell ls-files to not recurse
>> directories, and there is no way to also get the file type.
> 
> To ls-files, no-recurse is an idiotic thing to ask.  The index is a
> flat structure that is read as a whole.  There is no recursion
> involved.

What about an option like --as-tree, so that ls-files will list the
files as they were in a tree, instead of a flat structure ?


Thanks  Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDQ0j4ACgkQscQJ24LbaURXoACffQ4iz6MsoeffEZEBib1b1KF8
NZsAoIUXa7OonWyFxfJ35mukBK/sddGr
=0nO7
-----END PGP SIGNATURE-----

[PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

The git-completion.bash script did not implemented full, git aware,
support to complete paths, for git commands that operate on files within
the current working directory or the index.

As an example:

	git add <TAB>

will suggest all files in the current working directory, including
ignored files and files that have not been modified.

Support path completion, for git commands where the non-option arguments
always refer to paths within the current working directory or the index,
as the follow:

* the path completion for the "git mv", "git rm" and "git ls-tree"
  commands will suggest all cached files.

* the path completion for the "git add" command will suggest all
  untracked and modified files.  Ignored files are excluded.

* the path completion for the "git clean" command will suggest all
  untracked files.  Ignored files are excluded.

* the path completion for the "git commit" command will suggest all
  files that have been modified from the HEAD.

For all affected commands, completion will always stop at directory
boundary.  Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.

Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
---

Changes from version 2:

	* Perl is no more used.
	* Fixed some coding style issues.
	* Refactorized code, to improve future path completion support for
	  the "git reset" command.

 contrib/completion/git-completion.bash | 127 ++++++++++++++++++++++++++++-----
 1 file changed, 111 insertions(+), 16 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b77eb1..fc12d0f 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
 #    *) .git/remotes file names
 #    *) git 'subcommands'
 #    *) tree paths within 'ref:path/to/file' expressions
+#    *) file paths within current working directory and index
 #    *) common --long-options
 #
 # To use these routines:
@@ -233,6 +234,58 @@ __gitcomp_nl ()
 	COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
 }
 
+# Process path list returned by "ls-files" and "diff-index --name-only"
+# commands, in order to list only file names relative to a specified
+# directory, and append a slash to directory names.
+# It accepts 1 optional argument: a directory path.  The path must have
+# a trailing slash.
+__git_index_file_list_filter ()
+{
+	local path
+
+	while read -r path; do
+		path=${path#$1}
+
+		case "$path" in
+		?*/*) echo "${path%%/*}/" ;;
+		*) echo $path ;;
+		esac
+	done
+}
+
+# __git_index_files accepts 1 or 2 arguments:
+# 1: A string for file index status mode ("c", "m", "d", "o"), as
+#    supported by git ls-files command.
+# 2: A directory path (optional).
+#    If provided, only files within the specified directory are listed.
+#    Sub directories are never recursed.  Path must have a trailing
+#    slash.
+__git_index_files ()
+{
+	local dir="$(__gitdir)"
+
+	if [ -d "$dir" ]; then
+		git --git-dir="$dir" ls-files --exclude-standard "-${1}" "${2}" |
+			__git_index_file_list_filter ${2} | uniq
+	fi
+}
+
+# __git_diff_index_files accepts 1 or 2 arguments:
+# 1) The id of a tree object.
+# 2) A directory path (optional).
+#    If provided, only files within the specified directory are listed.
+#    Sub directories are never recursed.  Path must have a trailing
+#    slash.
+__git_diff_index_files ()
+{
+	local dir="$(__gitdir)"
+
+	if [ -d "$dir" ]; then
+		git --git-dir="$dir" diff-index --name-only "${1}" |
+			__git_index_file_list_filter "${2}" | uniq
+	fi
+}
+
 __git_heads ()
 {
 	local dir="$(__gitdir)"
@@ -430,6 +483,46 @@ __git_complete_revlist_file ()
 }
 
 
+# __git_complete_index_file requires 1 argument: the file index
+# status mode
+__git_complete_index_file ()
+{
+	local pfx cur_="$cur"
+
+	case "$cur_" in
+		?*/*)
+			pfx="${cur_%/*}"
+			cur_="${cur_##*/}"
+			pfx="${pfx}/"
+
+			__gitcomp_nl "$(__git_index_files ${1} ${pfx})" "$pfx" "$cur_" ""
+			;;
+		*)
+			__gitcomp_nl "$(__git_index_files ${1})" "" "$cur_" ""
+			;;
+	esac
+}
+
+# __git_complete_diff_index_file requires 1 argument: the id of a tree
+# object
+__git_complete_diff_index_file ()
+{
+	local pfx cur_="$cur"
+
+	case "$cur_" in
+		?*/*)
+			pfx="${cur_%/*}"
+			cur_="${cur_##*/}"
+			pfx="${pfx}/"
+
+			__gitcomp_nl "$(__git_diff_index_files ${1} ${pfx})" "$pfx" "$cur_" ""
+			;;
+		*)
+			__gitcomp_nl "$(__git_diff_index_files ${1})" "" "$cur_" ""
+			;;
+	esac
+}
+
 __git_complete_file ()
 {
 	__git_complete_revlist_file
@@ -770,8 +863,6 @@ _git_apply ()
 
 _git_add ()
 {
-	__git_has_doubledash && return
-
 	case "$cur" in
 	--*)
 		__gitcomp "
@@ -780,7 +871,9 @@ _git_add ()
 			"
 		return
 	esac
-	COMPREPLY=()
+
+	# XXX should we check for --update and --all options ?
+	__git_complete_index_file "om"
 }
 
 _git_archive ()
@@ -930,15 +1023,15 @@ _git_cherry_pick ()
 
 _git_clean ()
 {
-	__git_has_doubledash && return
-
 	case "$cur" in
 	--*)
 		__gitcomp "--dry-run --quiet"
 		return
 		;;
 	esac
-	COMPREPLY=()
+
+	# XXX should we check for -x option ?
+	__git_complete_index_file "o"
 }
 
 _git_clone ()
@@ -969,8 +1062,6 @@ _git_clone ()
 
 _git_commit ()
 {
-	__git_has_doubledash && return
-
 	case "$cur" in
 	--cleanup=*)
 		__gitcomp "default strip verbatim whitespace
@@ -997,8 +1088,10 @@ _git_commit ()
 			--verbose --quiet --fixup= --squash=
 			"
 		return
+		;;
 	esac
-	COMPREPLY=()
+
+	__git_complete_diff_index_file "HEAD"
 }
 
 _git_describe ()
@@ -1216,8 +1309,6 @@ _git_init ()
 
 _git_ls_files ()
 {
-	__git_has_doubledash && return
-
 	case "$cur" in
 	--*)
 		__gitcomp "--cached --deleted --modified --others --ignored
@@ -1230,7 +1321,10 @@ _git_ls_files ()
 		return
 		;;
 	esac
-	COMPREPLY=()
+
+	# XXX ignore options like --modified and always suggest all cached
+	# files.
+	__git_complete_index_file "c"
 }
 
 _git_ls_remote ()
@@ -1362,7 +1456,9 @@ _git_mv ()
 		return
 		;;
 	esac
-	COMPREPLY=()
+
+	# XXX needs more work
+	__git_complete_index_file "c"
 }
 
 _git_name_rev ()
@@ -2068,15 +2164,14 @@ _git_revert ()
 
 _git_rm ()
 {
-	__git_has_doubledash && return
-
 	case "$cur" in
 	--*)
 		__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
 		return
 		;;
 	esac
-	COMPREPLY=()
+
+	__git_complete_index_file "c"
 }
 
 _git_shortlog ()
-- 
1.8.1.rc1.18.g9db0d25

Re: [PATCH v3] git-completion.bash: add support for path completion

[Junio C Hamano]

[jch: again, adding area experts to Cc]

Manlio Perillo <manlio.perillo@gmail.com> writes:

> Changes from version 2:
>
> 	* Perl is no more used.
> 	* Fixed some coding style issues.
> 	* Refactorized code, to improve future path completion support for
> 	  the "git reset" command.

Thanks.  Will replace what was queued on 'pu'.

> +# Process path list returned by "ls-files" and "diff-index --name-only"
> +# commands, in order to list only file names relative to a specified
> +# directory, and append a slash to directory names.
> +# It accepts 1 optional argument: a directory path.  The path must have
> +# a trailing slash.

The callsites that call this function, and the way the argument is
used, do not make it look like it is an optional argument to me.

After reading later parts of the patch, I think the callers are
wrong (see below) and you did intend to make "$1" optional.

> +__git_index_file_list_filter ()
> +{
> +	local path
> +
> +	while read -r path; do
> +		path=${path#$1}

This will work correctly only if $1 does not have any shell
metacharacter that removes prefix of $path that matches $1 as a
pathname expansion pattern.  As this file is for bash completion,
using string-oriented Bash-isms like ${#1} (to get the length of the
prefix) and ${path:$offset} (to get substring) are perfectly fine
way to correct it.

Also, as $1 is optional, won't this barf if it is run under "set -u"?

> +# __git_index_files accepts 1 or 2 arguments:
> +# 1: A string for file index status mode ("c", "m", "d", "o"), as
> +#    supported by git ls-files command.
> +# 2: A directory path (optional).
> +#    If provided, only files within the specified directory are listed.
> +#    Sub directories are never recursed.  Path must have a trailing
> +#    slash.
> +__git_index_files ()
> +{
> +	local dir="$(__gitdir)"
> +
> +	if [ -d "$dir" ]; then
> +		git --git-dir="$dir" ls-files --exclude-standard "-${1}" "${2}" |
> +			__git_index_file_list_filter ${2} | uniq

Even though everywhere else you seem to quote the variables with dq,
but this ${2} is not written as "${2}", which looks odd.  Deliberate?

If you wanted to call __git_index_file_list_filter without parameter
when the caller did not give you the optional $2, then the above is
not the way to write it.  It would be ${2+"$2"}.  The upstream of
the pipe (ls-files) also is getting an empty string as the pathspec
when $2 is omitted, and the call will break if this is run under
"set -u".

> +# __git_diff_index_files accepts 1 or 2 arguments:
> +# 1) The id of a tree object.
> +# 2) A directory path (optional).
> +#    If provided, only files within the specified directory are listed.
> +#    Sub directories are never recursed.  Path must have a trailing
> +#    slash.
> +__git_diff_index_files ()
> +{
> +	local dir="$(__gitdir)"
> +
> +	if [ -d "$dir" ]; then
> +		git --git-dir="$dir" diff-index --name-only "${1}" |
> +			__git_index_file_list_filter "${2}" | uniq

This one, when the optional $2 is absent, will call __git_index_file_list_filter
with an empty string in its "$1".  Intended, or is it also ${2+"$2"}?

> +# __git_complete_index_file requires 1 argument: the file index
> +# status mode
> +__git_complete_index_file ()
> +{
> +	local pfx cur_="$cur"
> +
> +	case "$cur_" in
> +		?*/*)
> +			pfx="${cur_%/*}"
> +			cur_="${cur_##*/}"
> +			pfx="${pfx}/"
> +
> +			__gitcomp_nl "$(__git_index_files ${1} ${pfx})" "$pfx" "$cur_" ""
> +			;;
> +		*)
> +			__gitcomp_nl "$(__git_index_files ${1})" "" "$cur_" ""
> +			;;
> +	esac

Please dedent the case arms by one level, i.e.

	case $value in
        $pattern1)
        	action1
                ;;
                ...
		;;
	esac

> +# __git_complete_diff_index_file requires 1 argument: the id of a tree
> +# object
> +__git_complete_diff_index_file ()
> +{
> +	local pfx cur_="$cur"
> +
> +	case "$cur_" in
> +		?*/*)
> +			pfx="${cur_%/*}"
> +			cur_="${cur_##*/}"
> +			pfx="${pfx}/"
> +
> +			__gitcomp_nl "$(__git_diff_index_files ${1} ${pfx})" "$pfx" "$cur_" ""
> +			;;
> +		*)
> +			__gitcomp_nl "$(__git_diff_index_files ${1})" "" "$cur_" ""
> +			;;

Unquoted $1 looks fishy, even if the only caller of this function
always gives "HEAD" to it (in which case you can do without making
it a parameter in the first place).

Unquoted ${pfx} given to __git_diff_index_files also looks fishy.

Re: [PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 19/12/2012 20:57, Junio C Hamano ha scritto:
> [jch: again, adding area experts to Cc]
> 
> Manlio Perillo <manlio.perillo@gmail.com> writes:
> 
>> Changes from version 2:
>>
>> 	* Perl is no more used.
>> 	* Fixed some coding style issues.
>> 	* Refactorized code, to improve future path completion support for
>> 	  the "git reset" command.
> 
> Thanks.  Will replace what was queued on 'pu'.
> 
>> +# Process path list returned by "ls-files" and "diff-index --name-only"
>> +# commands, in order to list only file names relative to a specified
>> +# directory, and append a slash to directory names.
>> +# It accepts 1 optional argument: a directory path.  The path must have
>> +# a trailing slash.
> 
> The callsites that call this function, and the way the argument is
> used, do not make it look like it is an optional argument to me.
> 
> After reading later parts of the patch, I think the callers are
> wrong (see below) and you did intend to make "$1" optional.
> 

Thanks for the corrections.
As you can see, I'm not very expert in bash programming.
I will review the code to use proper escaping and correct optional
parameters handling, based on your review.

In this case, I incorrectly assumed that bash expands ${1} to an empty
string, in case no arguments are passed to the function.

>> +__git_index_file_list_filter ()
>> +{
>> +	local path
>> +
>> +	while read -r path; do
>> +		path=${path#$1}
> 
> This will work correctly only if $1 does not have any shell
> metacharacter that removes prefix of $path that matches $1 as a
> pathname expansion pattern.  As this file is for bash completion,
> using string-oriented Bash-isms like ${#1} (to get the length of the
> prefix) and ${path:$offset} (to get substring) are perfectly fine
> way to correct it.
> 

Ok.

> Also, as $1 is optional, won't this barf if it is run under "set -u"?
>

Ok.
Here I should use ${1-}.

>> +# __git_index_files accepts 1 or 2 arguments:
>> +# 1: A string for file index status mode ("c", "m", "d", "o"), as
>> +#    supported by git ls-files command.
>> +# 2: A directory path (optional).
>> +#    If provided, only files within the specified directory are listed.
>> +#    Sub directories are never recursed.  Path must have a trailing
>> +#    slash.
>> +__git_index_files ()
>> +{
>> +	local dir="$(__gitdir)"
>> +
>> +	if [ -d "$dir" ]; then
>> +		git --git-dir="$dir" ls-files --exclude-standard "-${1}" "${2}" |
>> +			__git_index_file_list_filter ${2} | uniq
> 
> Even though everywhere else you seem to quote the variables with dq,
> but this ${2} is not written as "${2}", which looks odd.  Deliberate?
> 

No, I simply missed it.

> If you wanted to call __git_index_file_list_filter without parameter
> when the caller did not give you the optional $2, then the above is
> not the way to write it.  It would be ${2+"$2"}.

Yes, this seems the better solution.

> [...]

>> +# __git_diff_index_files accepts 1 or 2 arguments:
>> +# 1) The id of a tree object.
>> +# 2) A directory path (optional).
>> +#    If provided, only files within the specified directory are listed.
>> +#    Sub directories are never recursed.  Path must have a trailing
>> +#    slash.
>> +__git_diff_index_files ()
>> +{
>> +	local dir="$(__gitdir)"
>> +
>> +	if [ -d "$dir" ]; then
>> +		git --git-dir="$dir" diff-index --name-only "${1}" |
>> +			__git_index_file_list_filter "${2}" | uniq
> 
> This one, when the optional $2 is absent, will call __git_index_file_list_filter
> with an empty string in its "$1".  Intended, or is it also ${2+"$2"}?

No, it was not intended. But here it should probably be ${2-}.

One possible rule is:
    * ${n+"$n"} should be used by the _git_complete_xxx_file function;
    * ${n-} should be used by the _git_xxx_file functions

The alternative is for each function to use ${n-}, or {n+"$n"}.

But I'm not sure.  What is the best practice in bash for optional
parameters "propagation"?


> 
>> +# __git_complete_index_file requires 1 argument: the file index
>> +# status mode
>> +__git_complete_index_file ()
>> +{
>> +	local pfx cur_="$cur"
>> +
>> +	case "$cur_" in
>> +		?*/*)
>> +			pfx="${cur_%/*}"
>> +			cur_="${cur_##*/}"
>> +			pfx="${pfx}/"
>> +
>> +			__gitcomp_nl "$(__git_index_files ${1} ${pfx})" "$pfx" "$cur_" ""
>> +			;;
>> +		*)
>> +			__gitcomp_nl "$(__git_index_files ${1})" "" "$cur_" ""
>> +			;;
>> +	esac
> 
> Please dedent the case arms by one level, i.e.
>

I missed it.
Vim do not intent correctly this, and I forgot to dedent.


> [...]
>> +# __git_complete_diff_index_file requires 1 argument: the id of a tree
>> +# object
>> +__git_complete_diff_index_file ()
>> +{
>> +	local pfx cur_="$cur"
>> +
>> +	case "$cur_" in
>> +		?*/*)
>> +			pfx="${cur_%/*}"
>> +			cur_="${cur_##*/}"
>> +			pfx="${pfx}/"
>> +
>> +			__gitcomp_nl "$(__git_diff_index_files ${1} ${pfx})" "$pfx" "$cur_" ""
>> +			;;
>> +		*)
>> +			__gitcomp_nl "$(__git_diff_index_files ${1})" "" "$cur_" ""
>> +			;;
> 
> Unquoted $1 looks fishy, even if the only caller of this function
> always gives "HEAD" to it (in which case you can do without making
> it a parameter in the first place).
> 

Currently it is always "HEAD", but in future it may contain an arbitrary
tree-ish (for my planned "git reset" path completion support).
This is the reason why in version 3 of the patch I added this new
__git_complete_diff_index_file function.

Better to quote it.

> Unquoted ${pfx} given to __git_diff_index_files also looks fishy.

I missed it.


Thanks   Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDSN30ACgkQscQJ24LbaUQPRQCgkQaDyBeXjk5gMJsufGoe9FCe
yDkAn2M4d1xRYSkF6P0lQQmENlbYiCb8
=iml7
-----END PGP SIGNATURE-----

Re: [PATCH v3] git-completion.bash: add support for path completion

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 19/12/2012 20:57, Junio C Hamano ha scritto:
> [...]

I just found a serious bug with "git commit" path completion.

When doing the first commit on an empty repository, completion will
cause an error:

$git commit -m init <TAB>fatal: ambiguous argument 'HEAD': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

The problem is that for a newly created repository there is no HEAD.

If HEAD does not exists, code must use ls-files instead of diff-index
to get the completion list.

Another change is to always call git commands with stderr redirected to
/dev/null.


By the way, this is also a bug of current bash completion code:

    $ git show does-not-exists:<TAB>fatal: Not a valid object name
      does-not-exists

I will write a patch (based on master) to fix this.

> [...]


Regards  Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlDSUR0ACgkQscQJ24LbaUSkRwCfVKk9JhSD4sKDFm4heAkVbN0o
KAAAn3paTXyUiFlfY/UBpnkwiARegLsE
=7Q5s
-----END PGP SIGNATURE-----