From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 17 Dec 2012 19:42:04 GMT
Subject: Re: [PATCH] git-completion.bash: add support for path completion
Message-ID: <7vzk1clb3n.fsf@alter.siamese.dyndns.org>
In-Reply-To: <50CEFF3A.4050802@gmail.com>

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

>> 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.

That sounds like a regression to me.

>> 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.

I deliberately wrote "the last" not "the second", as you can do

	$ mkdir X
        $ git mv COPYING README X/.

You do need to expand the second parameter to README when the user
types

	git mv COPYING REAMDE X

then goes back with \C-b to "M", types \C-d three times to remove
"MDE", and then finally says <TAB>, to result in

	git mv COPYING README X