Re: broken bash completion

["SZEDER Gábor" <szeder@ira.uka.de>]

Hi,


On Wed, May 02, 2012 at 10:09:26PM +0800, Rolf Leggewie wrote:
> Current bash completion works the following way.
> 
> 1) only tag-completion possible: complete tag as much as possible
> 2) only file/dir-completion possible: complete path as much as possible
> 3) all of tag/file/dir-completion possible: complete tag (!) as much
> as possible
> 
> 1 and 2 are fine, but for #3 git should really stop at the lowest
> common denominator for all of tags, files and directories. This is
> explained better in above tickets, but I'll also include an example
> here for illustration.  Let's say I had tags debian/1.4.9-1 and
> debian/1.4.9-2 as well as debian/changelog file (as is common when
> using git-buildpackage, this is a real life example).  Current
> bash-completion behavior for "git log debiTAB" is to complete to
> "git log debian/1.4.9-"

Yeah, there are a lot of git commands that accept refs (not just tags)
and files as well.  When completing a non-option word (i.e. a word
that does not begin with a double dash) for such a command, git's
completion script offers only refs, but when none of the refs matches
the word to be completed, then COMPREPLY remains empty and Bash falls
back to the default filename completion.

Now, to resolve ambiguity between options/refs and paths, the '--'
separator should be used before the first path to separate options and
refs from paths.  The completion script recognizes this separator, and
lets Bash perform filename completion for subsequent words.  So if you
know that you want to complete a file, then 'git log -- d<TAB>' will
give you 'debian/'.  Alternatively, you can just prefix './' to the
path, e.g. write 'git log ./d<TAB>' to get './debian/'.

> when it really should be "git log debian/".

I understand why you think that offering 'debian/' there would be the
correct behavior.  However, in this case being correct is perhaps not
the right thing.  Currently 'git log c<TAB>' offers me a couple of
completion-related branches, but with your correct behavior that would
be cluttered by all files and directories starting with 'c'.  I for
one would find that inconvenient and annoying, especially because,
while there are easy ways to get filename completion instead of refs,
as shown above, there is no similarly easy way to get only refs
completion.  


Best,
Gábor