git checkout improvement

git checkout improvement

[Clint Adams]

Maybe we should abstract the words[(I)--] bit into some kind of
_git_arguments function.

From: Mikael Magnusson <mikachu@gmail.com>
Date: Wed, 20 Aug 2008 02:07:33 +0000 (+0200)
Subject: _git: Make git checkout completion better.
X-Git-Url: http://git.mika.l3ib.org:1234/?p=zsh-cvs.git;a=commitdiff_plain;h=ac165daf55008c6ac06c1ef7627a80a358b7342d

_git: Make git checkout completion better.

Now -- works, and you can complete more than one file for the second
invocation form. Like the added XXX says, if you type
git checkout -q HEAD <tab>
then it tries to use -q as a treeish, which obviously doesn't work out.
---

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 64ea8de..6603371 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -1543,24 +1543,29 @@ _git-checkout () {
     new_branch_reflog_arg='-l[create the new branch'\''s reflog]'
   fi
 
-  # TODO: This isn’t quite correct in regards of the handling of the “--”
-  # option, as it should prevent us from seeing a branch, not stop matching
-  # options.
-  _arguments -C -S -A "-*" \
-    - switch-branch \
-      '-q[suppress feedback messages]' \
-      '-f[force a complete re-read]' \
-      '-b[create a new branch based at given branch]: :__git_guard_branch-name' \
-      {-t,--track}'[set up configuration so pull merges from the start point]' \
-      '--no-track[override the branch.autosetupmerge configuration variable]' \
-      '-l[create the branch'\''s reflog]' \
-      $new_branch_reflog_arg \
-      '-m[3way merge current branch, working tree and new branch]' \
-      '::branch:__git_revisions' \
-    - update-files \
-      '::tree-ish:__git_tree_ishs' \
-      '::file:->files' && ret=0
+  if (( words[(I)--] > 0 && words[(I)--] < CURRENT )); then
+    _arguments -C -S \
+      - update-files \
+        '*::file:->files' && ret=0
+  else
+    _arguments -C -S \
+      - switch-branch \
+        '-q[suppress feedback messages]' \
+        '-f[force a complete re-read]' \
+        '-b[create a new branch based at given branch]: :__git_guard_branch-name' \
+        {-t,--track}'[set up configuration so pull merges from the start point]' \
+        '--no-track[override the branch.autosetupmerge configuration variable]' \
+        '-l[create the branch'\''s reflog]' \
+        $new_branch_reflog_arg \
+        '-m[3way merge current branch, working tree and new branch]' \
+        '::branch:__git_revisions' \
+      - update-files \
+        '::tree-ish:__git_tree_ishs' \
+        '*::file:->files' && ret=0
+  fi
 
+  #XXX TODO and all that: $line[1] only works if you didn't write any options.
+  #What's the variable that holds the tree-ish argument? Is it even reliably possible?
   case $state in
     (files)
       if [[ -n $line[1] ]]; then

Re: git checkout improvement

[Mikael Magnusson]

2008/8/21 Clint Adams <clint@zsh.org>:
> Maybe we should abstract the words[(I)--] bit into some kind of
> _git_arguments function.

I also noticed completing files from the index doesn't work as well as
completing files from a given tree... eg, If you type
git checkout HEAD gi<tab>
you get git.c, but if you
git checkout -- gi<tab>
you get nothing. However,
git checkout -- <tab>
lists all the files, and lets you cycle through them until you reach git.c
It uses __git_cached_files for that case, but some other places that call
that work just fine with something already typed. You got any idea?

-- 
Mikael Magnusson

Re: git checkout improvement

[Clint Adams]

On Thu, Aug 21, 2008 at 02:20:49AM +0200, Mikael Magnusson wrote:
> I also noticed completing files from the index doesn't work as well as
> completing files from a given tree... eg, If you type
> git checkout HEAD gi<tab>
> you get git.c, but if you
> git checkout -- gi<tab>
> you get nothing. However,
> git checkout -- <tab>
> lists all the files, and lets you cycle through them until you reach git.c
> It uses __git_cached_files for that case, but some other places that call
> that work just fine with something already typed. You got any idea?

I am getting confused here.  Can you use -- when there's a tree-ish on
the line?

Re: git checkout improvement

[Mikael Magnusson]

2008/8/21 Clint Adams <clint@zsh.org>:
> On Thu, Aug 21, 2008 at 02:20:49AM +0200, Mikael Magnusson wrote:
>> I also noticed completing files from the index doesn't work as well as
>> completing files from a given tree... eg, If you type
>> git checkout HEAD gi<tab>
>> you get git.c, but if you
>> git checkout -- gi<tab>
>> you get nothing. However,
>> git checkout -- <tab>
>> lists all the files, and lets you cycle through them until you reach git.c
>> It uses __git_cached_files for that case, but some other places that call
>> that work just fine with something already typed. You got any idea?
>
> I am getting confused here.  Can you use -- when there's a tree-ish on
> the line?

Yes. All of these are valid commands:
git checkout git.c
git checkout HEAD git.c
git checkout -- git.c
git checkout HEAD -- git.c

-- 
Mikael Magnusson

Re: git checkout improvement

[Mikael Magnusson]

2008/8/21 Mikael Magnusson <mikachu@gmail.com>:
> 2008/8/21 Clint Adams <clint@zsh.org>:
>> On Thu, Aug 21, 2008 at 02:20:49AM +0200, Mikael Magnusson wrote:
>>> I also noticed completing files from the index doesn't work as well as
>>> completing files from a given tree... eg, If you type
>>> git checkout HEAD gi<tab>
>>> you get git.c, but if you
>>> git checkout -- gi<tab>
>>> you get nothing. However,
>>> git checkout -- <tab>
>>> lists all the files, and lets you cycle through them until you reach git.c
>>> It uses __git_cached_files for that case, but some other places that call
>>> that work just fine with something already typed. You got any idea?
>>
>> I am getting confused here.  Can you use -- when there's a tree-ish on
>> the line?
>
> Yes. All of these are valid commands:
> git checkout git.c
> git checkout HEAD git.c
> git checkout -- git.c
> git checkout HEAD -- git.c

Another problem is you can do
git checkout git.c NEWS
but then we try to use git.c as a tree-ish which obviously doesn't work.
Probably we should check if words[1] (or whatever) is a valid tree-ish,
and if not, complete files from the index instead.

-- 
Mikael Magnusson

Re: git checkout improvement

[Clint Adams]

On Thu, Aug 21, 2008 at 04:22:08AM +0200, Mikael Magnusson wrote:
> Another problem is you can do
> git checkout git.c NEWS
> but then we try to use git.c as a tree-ish which obviously doesn't work.
> Probably we should check if words[1] (or whatever) is a valid tree-ish,
> and if not, complete files from the index instead.

Great, how do you validate a tree-ish?

Re: git checkout improvement

[Mikael Magnusson]

2008/8/21 Clint Adams <clint@zsh.org>:
> On Thu, Aug 21, 2008 at 04:22:08AM +0200, Mikael Magnusson wrote:
>> Another problem is you can do
>> git checkout git.c NEWS
>> but then we try to use git.c as a tree-ish which obviously doesn't work.
>> Probably we should check if words[1] (or whatever) is a valid tree-ish,
>> and if not, complete files from the index instead.
>
> Great, how do you validate a tree-ish?

This seems to work :)

commit b619c9a4c193380d8b974753257c60faf713f6f6
Author: Mikael Magnusson <mikachu@gmail.com>
Date:   Thu Aug 21 07:18:50 2008 +0200

    _git: Make sure the first argument is a treeish.

    The first rev-parse is needed in case the user wrote something
like HEAD:, HEAD:^{tree}
    is not valid syntax, so get the sha1 first and then append the ^{tree}.

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 6603371..7e48c19 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -1529,6 +1529,13 @@ _git-branch () {
 }
 __git_zstyle_default
':completion::complete:git-branch:delete-argument-rest:*' ignore-line
yes

+(( $+functions[__git_is_treeish] )) ||
+__git_is_treeish () {
+  local sha1
+  sha1="$(git rev-parse $1)"
+  [[ "$(git cat-file -t "${sha1}^{tree}" 2> /dev/null)" == tree ]]
+}
+
 # TODO: __git_tree_ishs is just stupid.  It should be giving us a list of tags
 # and perhaps also allow all that just with ^{tree} and so on.  Not quite sure
 # how to do that, though.
@@ -1568,7 +1575,7 @@ _git-checkout () {
   #What's the variable that holds the tree-ish argument? Is it even
reliably possible?
   case $state in
     (files)
-      if [[ -n $line[1] ]]; then
+      if [[ -n $line[1] ]] && __git_is_treeish $line[1]; then
         __git_tree_files . $line[1] && ret=0
       else
         __git_cached_files && ret=0


-- 
Mikael Magnusson