Re: broken bash completion

From: SZEDER Gábor <szeder@ira.uka.de>
Date: May 4, 2012, 23:32 UTC
Message-ID: <20120504233213.GF2164@goldbirke>
In-Reply-To: <4FA14016.8050503@rolf.leggewie.biz>

Hi,

On Wed, May 02, 2012 at 10:09:26PM +0800, Rolf Leggewie wrote:

Show 15 quoted lines

> 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