On Wed, Mar 28, 2012 at 03:17:13PM -0700, Junio C Hamano wrote: > Kerrick Staley <mail@xxxxxxxxxxxxxxxxx> writes: > > > The __git_ps1 function is defined in same script that defines Git's > > tab completions (contrib/completion/git-completion.bash). Since > > bash-completion loads completions on-the-fly in newer versions, the > > __git_ps1 function isn't immediately available in a new shell. How > > should this be handled? Should users just source git-completion.bash > > before they redefine $PS1? > > Sorry, I don't quite get it. "newer verions" of what? > > To me, completion scripts have always been to be dot-sourced early, making > sure inclusion happen before PS1 is used. Did we change anything recently > to break it???? No, it is not us. The bash-completion project used to look in something like /etc/bash_completions.d and load everything at shell startup. Packagers could then drop our git-completion file there, and everything just worked. But it made starting the shell very slow, as you loaded completions for commands that you were unlikely to ever run. Newer versions of bash-completions load as little as possible on startup. When you first try to tab-complete "git <tab>", _then_ it looks for a "git" file and loads it on the fly. So people who put ". /path/to/git-completion.bash" have nothing to worry about. Everything will work as normal. People who depend on dropping the file somewhere that bash-completion can find it (or who use a package which does so) will find that they do not have __git_ps1 at shell startup with newer versions of bash-completion. Those people will need to start sourcing the file themselves (or possibly bash-completion could do it, but it really feels like it is not their responsibility, as the prompt functions have nothing to do with completion). We can help them out by breaking the file apart into "must be loaded at startup" and "can be loaded dynamically" bits, so they don't end up loading more than they need to. -Peff -- 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