On Thu, 26. Jun 2008, Ingo Molnar wrote: > * Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> Ingo Molnar <mingo@xxxxxxx> writes: >>> * Matthieu Moy <Matthieu.Moy@xxxxxxx> wrote: >>> >>>> (BTW, git-foo is being obsoleted in favor of "git foo") >>> >>> hm, can Bash be taught to do command completion on 'git rer<tab>', like >>> it is able to do on git-rer<tab> ? >> >> contrib/completion/git-completion.bash in git repository. > > btw., i had to turn this off - it made certain types of file completions > almost unusable, by adding a 2-3 seconds delay (during which bash would > just spin around burning CPU time calculating its completion guesses). Perhaps it would be better when "ceiling dir" feature in git, and configured, so git don't waste time searching for git repositories where there aren't any. > and that was on a 3 GHz dual-core box ... I think this might depend more on filesystem used, and file hierarchy. And also probably on the number of branches... That said, I'm not fully happy with git bash completion[*1*] either: one of complaints is that when completing "filename." on filename with extension (for example to "filename.h") it sometimes treats "filename." as beiginning of "<rev1>..<rev2>", and completes to "filename..", even if there no 'filename' ref in repository. > so please do not remove the git-* commands, they are really useful. Well, they are not removed, just moved aside (to address complaints of cluttering $PATH with 130+ programs), and I think that you can always install everything into /usr/bin/, as usual. Although it would be nice to be able to move aside only internal (*--*) commands, or perhaps even internal and plumbing. Footnotes: ========== [*1*] I wonder how zsh git completion fares in comparison. -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
