[PATCH 0/4] Batch completion improvements

[PATCH 0/4] Batch completion improvements

[Ramkumar Ramachandra]

Hi,

An older iteration of [2/4] was just reviewed by SZEDER on the list.
[1/4] and [3/4] have been sent out in the past, but haven't been
picked up.  [4/4] is new.

Thanks.

Ramkumar Ramachandra (4):
  completion: complete rebase --edit-todo
  completion: add completer for status
  completion: add completer for rev-parse
  completion: prefer to use local git-completion.bash

 contrib/completion/git-completion.bash | 45 ++++++++++++++++++++++++++++++++++
 contrib/completion/git-completion.zsh  |  2 +-
 2 files changed, 46 insertions(+), 1 deletion(-)

-- 
1.8.3.1.585.g9832cb9

[PATCH 1/4] completion: complete rebase --edit-todo

[Ramkumar Ramachandra]

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 contrib/completion/git-completion.bash | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 6c3bafe..b51c9e3 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1609,6 +1609,10 @@ _git_rebase ()
 {
 	local dir="$(__gitdir)"
 	if [ -d "$dir"/rebase-apply ] || [ -d "$dir"/rebase-merge ]; then
+		if [ -e "$dir"/rebase-merge/interactive ]; then
+			__gitcomp "--continue --skip --abort --edit-todo"
+			return
+		fi
 		__gitcomp "--continue --skip --abort"
 		return
 	fi
-- 
1.8.3.1.585.g9832cb9

[PATCH 2/4] completion: add completer for status

[Ramkumar Ramachandra]

Helped-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 contrib/completion/git-completion.bash | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b51c9e3..278018f 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1699,6 +1699,33 @@ _git_stage ()
 	_git_add
 }
 
+_git_status ()
+{
+	case "$cur" in
+	--untracked-files=*)
+		__gitcomp "no normal all" "" "${cur##--untracked-files=}"
+		return
+		;;
+	--ignore-submodules=*)
+		__gitcomp "none untracked dirty all" "" "${cur##--ignore-submodules=}"
+		return
+		;;
+	--column=*)
+		__gitcomp "always never auto column row plain dense nodense" "" "${cur##--column=}"
+		return
+		;;
+	--*)
+		__gitcomp "
+			--short --branch --long --porcelain --ignored
+			--untracked-files --ignore-submodules --column
+			--untracked-files= --ignore-submodules= --column=
+			"
+		return
+		;;
+	esac
+	__git_complete_index_file "--with-tree=HEAD --cached --others"
+}
+
 __git_config_get_set_variables ()
 {
 	local prevword word config_file= c=$cword
-- 
1.8.3.1.585.g9832cb9

[PATCH 3/4] completion: add completer for rev-parse

[Ramkumar Ramachandra]

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 contrib/completion/git-completion.bash | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 278018f..f2959a7 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2247,6 +2247,20 @@ _git_reset ()
 	__gitcomp_nl "$(__git_refs)"
 }
 
+_git_rev_parse ()
+{
+	case "$cur" in
+	--*)
+		__gitcomp "
+			--short --show-toplevel --is-inside-work-tree
+			--symbolic-full-name --verify
+			"
+               return
+               ;;
+	esac
+	__gitcomp_nl "$(__git_refs)"
+}
+
 _git_revert ()
 {
 	case "$cur" in
-- 
1.8.3.1.585.g9832cb9

[PATCH 4/4] completion: prefer to use local git-completion.bash

[Ramkumar Ramachandra]

git-completion.zsh looks in various "default" locations for
git-completion.bash.  During development, the location

  $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash

is the most obvious and up-to-date version.  Push it up on the list of
locations.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
 contrib/completion/git-completion.zsh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.zsh b/contrib/completion/git-completion.zsh
index fac5e71..6fca145 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -30,10 +30,10 @@ if [ -z "$script" ]; then
 	local -a locations
 	local e
 	locations=(
+		$(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
 		'/etc/bash_completion.d/git' # fedora, old debian
 		'/usr/share/bash-completion/completions/git' # arch, ubuntu, new debian
 		'/usr/share/bash-completion/git' # gentoo
-		$(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
 		)
 	for e in $locations; do
 		test -f $e && script="$e" && break
-- 
1.8.3.1.585.g9832cb9

Re: [PATCH 3/4] completion: add completer for rev-parse

[SZEDER Gábor]

On Fri, Jun 28, 2013 at 07:48:07PM +0530, Ramkumar Ramachandra wrote:
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
>  contrib/completion/git-completion.bash | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 278018f..f2959a7 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -2247,6 +2247,20 @@ _git_reset ()
>  	__gitcomp_nl "$(__git_refs)"
>  }
>  
> +_git_rev_parse ()
> +{
> +	case "$cur" in
> +	--*)
> +		__gitcomp "
> +			--short --show-toplevel --is-inside-work-tree
> +			--symbolic-full-name --verify
> +			"

In the completion script we support porcelain commands.  I'm not sure
about 'git rev-parse', but I think it's more plumbing than porcelain.
However, I think the same about 'git ls-tree' and 'git reflog', too,
yet we have support for them in the completion script.

Either way, why these five options?  'git rev-parse' has a lot more
options than that.


> +               return
> +               ;;
> +	esac
> +	__gitcomp_nl "$(__git_refs)"
> +}
> +
>  _git_revert ()
>  {
>  	case "$cur" in
> -- 
> 1.8.3.1.585.g9832cb9
> 

Re: [PATCH 3/4] completion: add completer for rev-parse

[Ramkumar Ramachandra]

SZEDER Gábor wrote:
> Either way, why these five options?  'git rev-parse' has a lot more
> options than that.

We have to start somewhere, so I put in the options that I personally use.

Re: [PATCH 2/4] completion: add completer for status

[SZEDER Gábor]

On Fri, Jun 28, 2013 at 07:48:06PM +0530, Ramkumar Ramachandra wrote:
> +	__git_complete_index_file "--with-tree=HEAD --cached --others"

The code is OK, the rest of the function is pretty straightforward,
but I think this line would warrant a sentence in the log message,
considering that at first you also wondered what '--with-tree=HEAD' is
about.

Re: [PATCH 2/4] completion: add completer for status

[Ramkumar Ramachandra]

SZEDER Gábor wrote:
> The code is OK, the rest of the function is pretty straightforward,
> but I think this line would warrant a sentence in the log message,

Okay.

  Complete untracked pathspecs (--others), and overlay HEAD tree on
index (--with-tree=HEAD) to complete pathspecs that have been removed
from the filesystem + staged in the index.

Re: [PATCH 3/4] completion: add completer for rev-parse

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

> On Fri, Jun 28, 2013 at 07:48:07PM +0530, Ramkumar Ramachandra wrote:
>> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
>> ---
>>  contrib/completion/git-completion.bash | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>> 
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index 278018f..f2959a7 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -2247,6 +2247,20 @@ _git_reset ()
>>  	__gitcomp_nl "$(__git_refs)"
>>  }
>>  
>> +_git_rev_parse ()
>> +{
>> +	case "$cur" in
>> +	--*)
>> +		__gitcomp "
>> +			--short --show-toplevel --is-inside-work-tree
>> +			--symbolic-full-name --verify
>> +			"
>
> In the completion script we support porcelain commands.  I'm not sure
> about 'git rev-parse', but I think it's more plumbing than porcelain.
> However, I think the same about 'git ls-tree' and 'git reflog', too,
> yet we have support for them in the completion script.
>
> Either way, why these five options?  'git rev-parse' has a lot more
> options than that.

I think most of the options not listed here are indeed very low
level plumbings that end users have no reason to type on the command
line, except when they are learning to see how they would use it in
their scripts, of course.

Adding a select few that current Git gives no other easy way to
achieve what the users may want to do is a good short-to-medium term
compromise for usability, and I think the above is a good starting
point.

But our goal should be _not_ to grow that set, but to shrink them by
making "rev-parse" less end-user facing.

A longer term direction should be to make sure that we do _not_ need
to run "rev-parse" from the command line by giving usability updates
to other commands and shell helpers, though.

For example, some subcommands of "git submodule" always required you
to run from the top-level, so you needed some way to find out where
the top level was, but the need to find the top-level is _not_ the
ultimate end-user _want_.  There was no other easy way to achieve
what the users wanted to do (i.e. run "git submodule foo" command)
without first finding out where the top-level is and to go there
before running it.  The user did not necessarily want to go there,
and giving an easy way to find the top may merely be a workaround.

The true solution for that particular issue may be to teach that
subcommand of "git submodule" to run from anywhere, which I think
has happened recently.

Another example on the same option.  Nobody should have to type

	$ cd $(git rev-parse --show-toplevel)

on the command line, even if there is a legitimate reason why it is
necessary to go to the top.  If it is common enough, just like we
ship completion and prompt in contrib/, we should ship a set of
common shell functions and aliases to let you do the above with:

	$ cdtop

which may be defined to be something like [*1*].

And these are illustrations of how we can lose needs to use that
option from the command line.  We should continue to go in that
direction.

For --short and --symbolic-full-name, I have a feeling that we
should make "describe" a front-end for these.

Just like "describe" already acts as a front-end for "name-rev" and
behaves differently, we treat the command as a way to transform an
object name into another form, and in addition to the current "do so
by expressing the given rev relative to an appropriate anchor point"
mode, teach it more ways to represent the given rev by doing
something different (e.g. these two are about expressing them as
themselves and not as relative to something else, so the "describe"
command in that mode would not walk the history to find nearby anchor
points).

As to completing "--verify", I can see how it may be useful for
people who interactively play with the command examples they find in
scripts, but otherwise I do not see much value for real end-users.

"rev-parse foobar" would say "foobar" if that does not refer to an
object and end users are more intelligent than a script to see the
difference without seeing the value of $? and error message when
running on the command line.


[Footnote]

*1* This is typed in my MUA for illustration purposes only, not
tested:

        cdtop () {
                local eh
                eh=$(git rev-parse --is-inside-work-tree) || return
                case "$eh" in
                true)
                        eh=$(git rev-parse --show-toplevel)
                        test -z "$eh" || cd "$eh"
                        ;;
                false)
                        eh=$(git rev-parse --git-dir) || return
                        cd "$eh" || return
                        eh=$(git rev-parse --is-bare-repository) || return
                        test "z$eh" = ztrue || cd ..
                        ;;
                esac
        }

Re: [PATCH 3/4] completion: add completer for rev-parse

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> For --short and --symbolic-full-name, I have a feeling that we
> should make "describe" a front-end for these.
> [...]

All very good.  If and when someone does write that functionality (I
personally find the task boring), we can remove this completer.  Until
such a time, the completer is useful and should be merged: so, could
you queue this series if there are no objections?