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

[Manlio Perillo <manlio.perillo@gmail.com>]

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

Il 17/12/2012 05:50, Junio C Hamano ha scritto:
> Manlio Perillo <manlio.perillo@gmail.com> writes:
> 
>> The git-completion.bash script did not implemented full support for
>> completion, for git commands that operate on files from the current
>> working directory or the index.
>>
>> For these commands, only options completion was available.
> 
> Hrm, "git mv CO<TAB>" completes it to "COPYING" for me.  Same for:
> 
>     git rm CO<TAB>
>     git clean Doc<TAB>
>     git commit --edit Doc<TAB>
> 
> There must be something missing from the above description, and the
> claim the above two paragraphs make does no make sense without that
> something that is missing.
> 

Thanks.

What is missing is that I forgot to explain that by "completion not
supported" I meant "*git aware* completion is not supported".

If you try, as an example, "git add <TAB>", bash will suggest *all*
files in your working directory, including ignored files and files with
no modifications.


>> * the path completion for the "git mv" and "git rm" commands is provided
>>   using "git ls-files --exclude-standard"
> 
> Does the above mean "git mv COPYING Doc<TAB>" would complete the
> command line to move it to Documentation/ directory?  
> 

It will suggest all tracked files from the Documentation directory.
One important detail is that it will recurse into sub directories.

This is not the behaviour of the current completion code.
The problem is that current code use ls-tree, and works only for paths
like <rev>:<path>.

My implementation use ls-files, that has a completly different interface
from ls-tree (and since I'm very new to git, this caused be some confusion).

It seems that with ls-files it is impossible to:

* get a list of path names without recursing into sub directories.
  (this is only possible for untracked directories)

* get the file mode for all "modified" or "deleted" files.

  If I do "git ls-files --stage --modified", git ignores the modified
  option and will list all files

> I think "using X" is of secondary importance.  Reviewers and future
> developers (who are reading "git log" output) can read it from the
> patch.  What is expected in the log message is why the implemenation
> was chosen, and in order to achieve what effect.
> 

Ok, thanks.

> 
>> * the path completion for the "git clean" command is provided using
>>   "git ls-files --exclude-standard -o"
>>
>> * the path completion for the "git commit" command is provides using
>>   "git diff-index --name-only HEAD"
> 
> As long as all of the above stops completion at directory boundary,
> I think the above sounds like a sensible thing to do.  e.g. when
> "ls-files" gives Documentation/Makefile and Documentation/git.txt,
> "git cmd Doc<TAB>" first would give "git cmd Documentation/" and
> then the second <TAB> would offer these two paths as choices.  That
> way, the user can choose to just execute "git cmd Documentation/"
> without even looking at these individual paths.
> 

Right, this is what bash usually do.
However I don't know how to implement this with git.

> I am not sure how you would handle the last parameter to "git mv",
> though.  That is by definition a path that does not exist,
> i.e. cannot be completed.
> 

Right, the code should be changed.
No completion should be done for the second parameter.



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

iEYEARECAAYFAlDO/zoACgkQscQJ24LbaUSD1ACfXeH2GizdNG/uzlSneEpdi1Na
6IoAni3ZrhhCMXbVoTqIVjH4mEX/XmaH
=w56v
-----END PGP SIGNATURE-----