{"thread":{"id":"30395","subject":"broken bash completion","startedAt":"2012-05-02T14:09:26Z","lastAt":"2012-05-05T14:26:18Z","messageCount":8,"participants":["Rolf Leggewie","SZEDER Gábor","Andreas Schwab","Felipe Contreras","fREW Schmidt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"190558","messageId":"4FA14016.8050503@rolf.leggewie.biz","threadId":"30395","inReplyTo":null,"subject":"broken bash completion","fromName":"Rolf Leggewie","fromEmail":"foss@rolf.leggewie.biz","sentAt":"2012-05-02T14:09:26Z","receivedAt":"2012-05-02T14:09:26Z","isPatch":false,"sender":{"key":"foss@rolf.leggewie.biz","avatar":null},"body":"forward from http://code.google.com/p/git-core/issues/detail?id=11\nand https://bugs.launchpad.net/bugs/853081\n\n\nHello,\n\nnot sure you guys pay much attention to the issue tracker over on \ncode.google.com so I'll try my luck here.\n\nCurrent bash completion works the following way.\n\n1) only tag-completion possible: complete tag as much as possible\n2) only file/dir-completion possible: complete path as much as possible\n3) all of tag/file/dir-completion possible: complete tag (!) as much as \npossible\n\n1 and 2 are fine, but for #3 git should really stop at the lowest common \ndenominator for all of tags, files and directories. This is explained \nbetter in above tickets, but I'll also include an example here for \nillustration. Let's say I had tags debian/1.4.9-1 and debian/1.4.9-2 as \nwell as debian/changelog file (as is common when using git-buildpackage, \nthis is a real life example). Current bash-completion behavior for \"git \nlog debiTAB\" is to complete to \"git log debian/1.4.9-\" when it really \nshould be \"git log debian/\".\n\nThank you for your attention.\n\nRegards\n\nRolf\n"},{"id":"190812","messageId":"20120504233213.GF2164@goldbirke","threadId":"30395","inReplyTo":"4FA14016.8050503@rolf.leggewie.biz","subject":"Re: broken bash completion","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2012-05-04T23:32:13Z","receivedAt":"2012-05-04T23:32:13Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi,\n\n\nOn Wed, May 02, 2012 at 10:09:26PM +0800, Rolf Leggewie wrote:\n> Current bash completion works the following way.\n> \n> 1) only tag-completion possible: complete tag as much as possible\n> 2) only file/dir-completion possible: complete path as much as possible\n> 3) all of tag/file/dir-completion possible: complete tag (!) as much\n> as possible\n> \n> 1 and 2 are fine, but for #3 git should really stop at the lowest\n> common denominator for all of tags, files and directories. This is\n> explained better in above tickets, but I'll also include an example\n> here for illustration. Let's say I had tags debian/1.4.9-1 and\n> debian/1.4.9-2 as well as debian/changelog file (as is common when\n> using git-buildpackage, this is a real life example). Current\n> bash-completion behavior for \"git log debiTAB\" is to complete to\n> \"git log debian/1.4.9-\"\n\nYeah, there are a lot of git commands that accept refs (not just tags)\nand files as well. When completing a non-option word (i.e. a word\nthat does not begin with a double dash) for such a command, git's\ncompletion script offers only refs, but when none of the refs matches\nthe word to be completed, then COMPREPLY remains empty and Bash falls\nback to the default filename completion.\n\nNow, to resolve ambiguity between options/refs and paths, the '--'\nseparator should be used before the first path to separate options and\nrefs from paths. The completion script recognizes this separator, and\nlets Bash perform filename completion for subsequent words. So if you\nknow that you want to complete a file, then 'git log -- d' will\ngive you 'debian/'. Alternatively, you can just prefix './' to the\npath, e.g. write 'git log ./d' to get './debian/'.\n\n> when it really should be \"git log debian/\".\n\nI understand why you think that offering 'debian/' there would be the\ncorrect behavior. However, in this case being correct is perhaps not\nthe right thing. Currently 'git log c' offers me a couple of\ncompletion-related branches, but with your correct behavior that would\nbe cluttered by all files and directories starting with 'c'. I for\none would find that inconvenient and annoying, especially because,\nwhile there are easy ways to get filename completion instead of refs,\nas shown above, there is no similarly easy way to get only refs\ncompletion. \n\n\nBest,\nGábor\n"},{"id":"190819","messageId":"4FA4AB86.8020108@rolf.leggewie.biz","threadId":"30395","inReplyTo":"20120504233213.GF2164@goldbirke","subject":"Re: broken bash completion","fromName":"Rolf Leggewie","fromEmail":"foss@rolf.leggewie.biz","sentAt":"2012-05-05T04:24:38Z","receivedAt":"2012-05-05T04:24:38Z","isPatch":false,"sender":{"key":"foss@rolf.leggewie.biz","avatar":null},"body":"Dear Gábor,\n\nthank you for taking the time to write up an analysis and offer some \nworkarounds to the bash-completion issue I reported. That is much \nappreciated.\n\nAfter all is said and done, though, the bash-completion remains \ninconsistent and thus broken. It's great that your life is currently \nmore convenient but in the end you are relying on broken behaviour.\n\nAffected commands:\ngit log\ngit diff\ngit whatchanged\ngit branch (why offer tags OR files here at all)\n[...]\n\nUnaffected programs, i.e. working correctly:\ngit commit\n[...]\n\nSome consistency would be great. In a perfect world bash-completion \nought to work on all possible completion targets but at the same time it \nshould exclude all that make no sense, too. Neither of the two seems to \nbe currently the case.\n\nI had a look at /etc/bash_completion.d/git to see if there was some work \nI could do to cook up a patch, but unfortunately, it's all greek to me \nin there.\n\nRegards\n\nRolf\n"},{"id":"190836","messageId":"20120505121319.GG2164@goldbirke","threadId":"30395","inReplyTo":"4FA4AB86.8020108@rolf.leggewie.biz","subject":"Re: broken bash completion","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2012-05-05T12:13:19Z","receivedAt":"2012-05-05T12:13:19Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi Rolf,\n\n\nOn Sat, May 05, 2012 at 12:24:38PM +0800, Rolf Leggewie wrote:\n> After all is said and done, though, the bash-completion remains\n> inconsistent and thus broken. It's great that your life is\n> currently more convenient but in the end you are relying on broken\n> behaviour.\n\nWell, git's completion script is consistent with itself: whenever\nthere is no matching subcommand, option, parameter for an option, or\nref, it falls back to filename completion. I wouldn't consider this\nbehavior as broken.\n\n> Affected commands:\n> git log\n> git diff\n> git whatchanged\n> git branch (why offer tags OR files here at all)\n\nWhile files and tags make no sense for 'git branch' itself, completing\nthem can be helpful to construct the name of a new branch. I did the\nfollowing at dayjob just the other day:\n\n# there are route_calculation.c and .h files in that project, and\n# there were some nasty bugs in there\n$ git branch ro\n# which gave me\n$ git branch route_calculation.\n# just deleted the '.' and completed the new branch name by hand\n$ git branch route_calculation_fixes\n\n\nAnyway, I see two ways to fix this if we want to be anal, but none of\nthem is actually applicable:\n\n- When registering _git() as the completion function for the git\n command, we specify some options to tell Bash to do filename\n completion when we can't find any matches to the word to be\n completed. Recent Bash versions provide the 'compopt' builtin to\n allow modifying completion options for the currently executed\n completion. We could do a 'compopt +o bashdefault +o default'\n to disable the filename completion fallback wherever we deem it\n inappropriate.\n\n 'compopt' was introduced in Bash 4.0, but unfortunately msysgit\n still includes an older version, so this is a no go.\n\n- We don't specify the options to ask Bash to fall back to filename\n completion when registering _git(). This will disable filename\n completion for the whole git completion script, so we must roll our\n own helper functions to do filename completion, which we would\n invoke wherever filename completion is explicitly desired.\n\n This should work on any Bash version, but would inherently include\n some fork()+exec()s, adding significant delays especially on\n msysgit.\n\n> Unaffected programs, i.e. working correctly:\n> git commit\n> [...]\n\nYou haven't tried it hard enough ;)\n\n$ git commit --fixup=e\neditor.c entry.c environment.c exec_cmd.c exec_cmd.o\neditor.o entry.o environment.o exec_cmd.h \n\nalthough at that point only a commit is accepted.\n\n> Some consistency would be great. In a perfect world bash-completion\n> ought to work on all possible completion targets but at the same\n> time it should exclude all that make no sense, too. Neither of the\n> two seems to be currently the case.\n\nYeah, in that perfect world 'git rm ', 'git bisect -- ', and\n'git log -- ' whould offer only tracked files, 'git (add|commit)\n' only modified or untracked files, and 'git diff ' would\nread your mind to find out whether you want to diff a ref or a file,\netc. etc.\n\nBut you miss an important point here: users expect the completion to\nbe pretty fast, because delays are quite noticeable and annoying while\ntyping a command. So there's a trade-off between correctness and\nusability. Unfortunately, in the real world all that filtering costs\na great deal, so git's completion script does that only if it can be\ndone cheaply (e.g. 'git rebase --' won't offer you '--abort' and\n'--continue' if you're not in the middle of an ongoing rebase). And\nas pointed out above, something might be nonsense for a command, but\nstill be useful for the user.\n\n\nBest,\nGábor\n"},{"id":"190838","messageId":"m2zk9mhl73.fsf@igel.home","threadId":"30395","inReplyTo":"20120505121319.GG2164@goldbirke","subject":"Re: broken bash completion","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-05-05T12:22:08Z","receivedAt":"2012-05-05T12:22:08Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"SZEDER Gábor writes:\n\n> While files and tags make no sense for 'git branch' itself, completing\n> them can be helpful to construct the name of a new branch. I did the\n> following at dayjob just the other day:\n>\n> # there are route_calculation.c and .h files in that project, and\n> # there were some nasty bugs in there\n> $ git branch ro\n\nYou can force filename completion with M-/.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"190840","messageId":"CAMP44s0q_zeVwzhgeda1=9+Psjr5PaO1QtHT1QC0RwyCpfd=rg@mail.gmail.com","threadId":"30395","inReplyTo":"20120505121319.GG2164@goldbirke","subject":"Re: broken bash completion","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-05T13:11:15Z","receivedAt":"2012-05-05T13:11:15Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, May 5, 2012 at 2:13 PM, SZEDER Gábor wrote:\n\n> But you miss an important point here: users expect the completion to\n> be pretty fast, because delays are quite noticeable and annoying while\n> typing a command.  So there's a trade-off between correctness and\n> usability.  Unfortunately, in the real world all that filtering costs\n> a great deal, so git's completion script does that only if it can be\n> done cheaply (e.g. 'git rebase --' won't offer you '--abort' and\n> '--continue' if you're not in the middle of an ongoing rebase).  And\n> as pointed out above, something might be nonsense for a command, but\n> still be useful for the user.\n\nCompletely agree with this.\n\nThe reason I started to use the bash completion in zsh is that the zsh\ncompletion goes for 100% correctness, that means 'git checkout '\ntook literally *minutes* in my machine on the Linux kernel repo. The\nzsh developers said that was OK, and my patch to solve the problem was\nnot, because it would make the result less than 100% correct.\n\nThe whole point of completion is to avoid typing as much as possible,\nand if typing something is faster than doing the completion; the\ncompletion is pointless. It has to be fast.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"190841","messageId":"CADVrmKRjw6VFQAnQruBmc1OhOaswpOtzb+E8G_KooYiz6SuStA@mail.gmail.com","threadId":"30395","inReplyTo":"CAMP44s0q_zeVwzhgeda1=9+Psjr5PaO1QtHT1QC0RwyCpfd=rg@mail.gmail.com","subject":"Re: broken bash completion","fromName":"fREW Schmidt","fromEmail":"frioux@gmail.com","sentAt":"2012-05-05T13:57:46Z","receivedAt":"2012-05-05T13:57:46Z","isPatch":false,"sender":{"key":"frioux@gmail.com","avatar":"https://gravatar.com/avatar/639ef3cc221c7f2c225568697bc9d42be4d4e3bada6b4a3b9c32685548f3c105?d=mp&s=160"},"body":"On Sat, May 5, 2012 at 8:11 AM, Felipe Contreras\n wrote:\n>\n> On Sat, May 5, 2012 at 2:13 PM, SZEDER Gábor wrote:\n>\n> The reason I started to use the bash completion in zsh is that the zsh\n> completion goes for 100% correctness, that means 'git checkout '\n> took literally *minutes* in my machine on the Linux kernel repo. The\n> zsh developers said that was OK, and my patch to solve the problem was\n> not, because it would make the result less than 100% correct.\n\nCould you elaborate on how you did that? I'm suffering from the same\nthing and don't see an obvious way to use bash-completion in zsh.\n\n--\nfREW Schmidt\nhttp://blog.afoolishmanifesto.com\n"},{"id":"190843","messageId":"CAMP44s0HtcO0S-Vjq=XkiB7VLZq-LWr2tf2MF_HMpj=1C=LKSQ@mail.gmail.com","threadId":"30395","inReplyTo":"CADVrmKRjw6VFQAnQruBmc1OhOaswpOtzb+E8G_KooYiz6SuStA@mail.gmail.com","subject":"Re: broken bash completion","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-05-05T14:26:18Z","receivedAt":"2012-05-05T14:26:18Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, May 5, 2012 at 3:57 PM, fREW Schmidt wrote:\n> On Sat, May 5, 2012 at 8:11 AM, Felipe Contreras\n> wrote:\n>>\n>> On Sat, May 5, 2012 at 2:13 PM, SZEDER Gábor wrote:\n>>\n>> The reason I started to use the bash completion in zsh is that the zsh\n>> completion goes for 100% correctness, that means 'git checkout '\n>> took literally *minutes* in my machine on the Linux kernel repo. The\n>> zsh developers said that was OK, and my patch to solve the problem was\n>> not, because it would make the result less than 100% correct.\n>\n> Could you elaborate on how you did that?  I'm suffering from the same\n> thing and don't see an obvious way to use bash-completion in zsh.\n\nJust source the bash script:\nhttp://git.kernel.org/?p=git/git.git;a=blob;f=contrib/completion/git-completion.bash\n\nAlternatively you can use my wrapper that works better than zsh's bash\ncompletion[1], but you still need the bash script anyway.\n\nCheers.\n\n[1] https://github.com/felipec/git-zsh/blob/master/git-completion.zsh\n\n-- \nFelipe Contreras\n"}]}