bash-completion now loads completions dynamically, so __git_ps1 is not defined when you open a shell

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?

-Kerrick Staley

Kerrick Staley <mail@kerrickstaley.com> writes:

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????

On Wed, Mar 28, 2012 at 03:17:13PM -0700, Junio C Hamano wrote:

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

Kerrick Staley wrote:

Yes, I think so. Do the release notes for version 2.0 of the /etc/bash_completion wrapper script mention this change?

Thanks, Jonathan

On Wed, Mar 28, 2012 at 5:17 PM, Junio C Hamano <gitster@pobox.com> wrote:

bash-completion 1.99 (still a "beta", but Arch Linux now ships it) will automatically source the git-completion.bash script when you type git <tab>. The script is no longer sourced when you first open a shell.

There are two main ways to fix this:
1) define __git_ps1 (and friends) in a different script, which will
get installed in /etc/profile.d (this is the "proper way")
2) require that git-completion.bash always be loaded in the beginning
instead of on-the-fly (which is how it works now now)

I can submit a patch implementing option (1) if needed.

This is a very minor issue, but some recommendation from upstream would be nice so that distros know how to handle this.

On Wed, Mar 28, 2012 at 6:06 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

I'm not sure, but the feature is definitely there. The branch implementing this feature has been merged into the project's master (see http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commit;h=b377dc5de84913b69efa325590e9d0bb97d02128).

-Kerrick

On Wed, Mar 28, 2012 at 07:00:35PM -0500, Kerrick Staley wrote:

I would much rather see (1). There is a very good reason for bash-completion doing dynamic loading, which is that loading all of the completions made shell startup horribly slow. We should do our part to help keep startup fast by splitting the dynamically-loadable bits from the must-be-loaded-at-start bits.

-Peff

On Thu, Mar 29, 2012 at 3:00 AM, Kerrick Staley <mail@kerrickstaley.com> wrote:

I prefer this because it's useful for zsh as well; not everybody uses the bash completion in zsh. I believe somebody already proposed this because of this reason. FWIW I named the script git-prompt.sh on my side.

Cheers.

Felipe Contreras wrote:

Sounds good to me. In fact, I imagine you'll find no one it does not sound good to. Please feel free to make it so.