[PATCH] bash prompt: add option to disable for a repository

[PATCH] bash prompt: add option to disable for a repository

[Heikki Hokkanen]

If bash.prompt is set to false, disable the prompt. This is useful
for huge repositories like the home directory.

Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
---
git-prompt.sh performance seems to be quite bad for big repositories, so
without a way to disable it selectively for repositories, it becomes unusable
for people who have their homedir under git. This patch generalizes the problem
a bit by allowing the prompt to be disabled by setting bash.prompt to false in
any repository.

 contrib/completion/git-prompt.sh | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 7b732d2..c982fde 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -84,6 +84,8 @@
 # GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
 # the colored output of "git status -sb" and are available only when
 # using __git_ps1 for PROMPT_COMMAND or precmd.
+#
+# To disable prompt for a repository, run "git config bash.prompt false"
 
 # check whether printf supports -v
 __git_printf_supports_v=
@@ -304,6 +306,12 @@ __git_ps1 ()
 		return
 	fi
 
+	local prompt_setting
+	prompt_setting=$(git config --bool bash.prompt)
+	if [ -n "$prompt_setting" ] && [ "$prompt_setting" == "false" ]; then
+		return
+	fi
+
 	local short_sha
 	if [ "$rev_parse_exit_code" = "0" ]; then
 		short_sha="${repo_info##*$'\n'}"
-- 
1.8.4

Re: [PATCH] bash prompt: add option to disable for a repository

[Johannes Sixt]

Am 23.11.2013 14:18, schrieb Heikki Hokkanen:
> If bash.prompt is set to false, disable the prompt. This is useful
> for huge repositories like the home directory.
> 
> Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
> ---
> git-prompt.sh performance seems to be quite bad for big repositories, so
> without a way to disable it selectively for repositories, it becomes unusable
> for people who have their homedir under git. This patch generalizes the problem
> a bit by allowing the prompt to be disabled by setting bash.prompt to false in
> any repository.
> 
>  contrib/completion/git-prompt.sh | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 7b732d2..c982fde 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -84,6 +84,8 @@
>  # GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
>  # the colored output of "git status -sb" and are available only when
>  # using __git_ps1 for PROMPT_COMMAND or precmd.
> +#
> +# To disable prompt for a repository, run "git config bash.prompt false"
>  
>  # check whether printf supports -v
>  __git_printf_supports_v=
> @@ -304,6 +306,12 @@ __git_ps1 ()
>  		return
>  	fi
>  
> +	local prompt_setting
> +	prompt_setting=$(git config --bool bash.prompt)
> +	if [ -n "$prompt_setting" ] && [ "$prompt_setting" == "false" ]; then
> +		return
> +	fi
> +

Gah! This adds a fork+exec each time the prompt is shown. Not good,
particularly on Windows.

Since your intent is to disable the prompt in the home directory,
wouldn't that mean that most of the time you *don't* want the prompt?
Wouldn't you be better served with a method that *turns on* the prompt?
For example, a shell function that sets PS1 and another one that unsets
it? Or a wrapper that inspects a shell variable and calls __git_ps1 only
when you want a prompt.

>  	local short_sha
>  	if [ "$rev_parse_exit_code" = "0" ]; then
>  		short_sha="${repo_info##*$'\n'}"
> 

-- Hannes

Re: [PATCH] bash prompt: add option to disable for a repository

[Heikki Hokkanen]

On Sat, Nov 23, 2013 at 4:42 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> Gah! This adds a fork+exec each time the prompt is shown. Not good,
> particularly on Windows.
>
> Since your intent is to disable the prompt in the home directory,
> wouldn't that mean that most of the time you *don't* want the prompt?
> Wouldn't you be better served with a method that *turns on* the prompt?
> For example, a shell function that sets PS1 and another one that unsets
> it? Or a wrapper that inspects a shell variable and calls __git_ps1 only
> when you want a prompt.

Actually, I do want the prompt for all other git repositories. The
problem with $HOME is that it's the default directory after logging in
or opening a terminal, so if you have git prompt sourced and your
$HOME under git, you get an unbearable delay every time you open a
terminal, or type a command, anywhere, except for a separate git
repository.

And I do believe I'm not the only one putting $HOME under git, so I
think some kind of generic solution to this problem would be nice.

If running git config on each prompt seems too expensive, do you have
any better ideas?

Regards,

-- 
Heikki Hokkanen

Re: [PATCH] bash prompt: add option to disable for a repository

[SZEDER Gábor]

Hi,

On Sat, Nov 23, 2013 at 03:18:23PM +0200, Heikki Hokkanen wrote:
> If bash.prompt is set to false, disable the prompt. This is useful
> for huge repositories like the home directory.
> 
> Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
> ---
> git-prompt.sh performance seems to be quite bad for big repositories,

Hm, strange.  I wonder what can cause performance problems in big
repositories.

Sure, there are status indicators that can be expensive, in particular
the indicators for dirty index/worktree, untracked files, and
divergence from upstream.  However, these must be enabled globally by
environment variables and even then can already be disabled on a
per-repo basis by configuration variables.  And the rest of the prompt
code should perform pretty much independently from the repository
size.

> so
> without a way to disable it selectively for repositories, it becomes unusable
> for people who have their homedir under git. This patch generalizes the problem
> a bit by allowing the prompt to be disabled by setting bash.prompt to false in
> any repository.
> 
>  contrib/completion/git-prompt.sh | 8 ++++++++
>  1 file changed, 8 insertions(+)

No tests.

> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 7b732d2..c982fde 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -84,6 +84,8 @@
>  # GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
>  # the colored output of "git status -sb" and are available only when
>  # using __git_ps1 for PROMPT_COMMAND or precmd.
> +#
> +# To disable prompt for a repository, run "git config bash.prompt false"
>  
>  # check whether printf supports -v
>  __git_printf_supports_v=
> @@ -304,6 +306,12 @@ __git_ps1 ()
>  		return
>  	fi
>  
> +	local prompt_setting
> +	prompt_setting=$(git config --bool bash.prompt)

I spent quite some time eliminating fork()s and exec()s from the
prompt, so a fork() for the command substitution's subshell and a
fork()+exec() for running a git command in the main code path saddens
me deeply ;)

> +	if [ -n "$prompt_setting" ] && [ "$prompt_setting" == "false" ]; then

If $prompt_setting must be false, then checking its non-emptyness is
superfluous.

> +		return

You can't just return from __git_ps1(), you must update PS1 in prompt
command mode.  See the few lines just above this hunk.

> +	fi
> +
>  	local short_sha
>  	if [ "$rev_parse_exit_code" = "0" ]; then
>  		short_sha="${repo_info##*$'\n'}"
> -- 
> 1.8.4
> 

Re: [PATCH] bash prompt: add option to disable for a repository

[Heikki Hokkanen]

Hello,

On Sat, Nov 23, 2013 at 6:35 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> Hm, strange.  I wonder what can cause performance problems in big
> repositories.
>
> Sure, there are status indicators that can be expensive, in particular
> the indicators for dirty index/worktree, untracked files, and
> divergence from upstream.  However, these must be enabled globally by
> environment variables and even then can already be disabled on a
> per-repo basis by configuration variables.  And the rest of the prompt
> code should perform pretty much independently from the repository
> size.

You are right. The performance issue seems to be indeed fixed by setting
bash.showDirtyState and bash.showUntrackedFiles to false. And I feel a
bit stupid for not realizing those were the only reason :)

Now the only remaining issue for me is that I wouldn't like to see git
prompt under the home directory repository, because then it's turned
on pretty much everywhere.

> I spent quite some time eliminating fork()s and exec()s from the
> prompt, so a fork() for the command substitution's subshell and a
> fork()+exec() for running a git command in the main code path saddens
> me deeply ;)

Seeing how the dirty state/untracked files/upstream configs are
implemented, I'm thinking, what if "bash.prompt" setting was checked
similarly only when something like GIT_PS1_PERREPOBASIS was set?

It would keep the default execution path free from added forks, but
still allow people to disable git prompt on a per-repository basis.

Regards,

-- 
Heikki Hokkanen

Re: [PATCH] bash prompt: add option to disable for a repository

[Jonathan Nieder]

Heikki Hokkanen wrote:

> If running git config on each prompt seems too expensive, do you have
> any better ideas?

Perhaps a GIT_PS1_NOT_FOR_THESE_REPOS=repo1:repo2:repo3 setting would
work.

__git_ps1 would do the one 'git rev-parse --git-dir --...' to find the
repo corresponding to the cwd and then could match against the
configured list to decide whether to return early.

Hope that helps,
Jonathan

Re: [PATCH] bash prompt: add option to disable for a repository

[SZEDER Gábor]

On Mon, Nov 25, 2013 at 03:43:44PM -0800, Jonathan Nieder wrote:
> Heikki Hokkanen wrote:
> 
> > If running git config on each prompt seems too expensive, do you have
> > any better ideas?
> 
> Perhaps a GIT_PS1_NOT_FOR_THESE_REPOS=repo1:repo2:repo3 setting would
> work.
> 
> __git_ps1 would do the one 'git rev-parse --git-dir --...' to find the
> repo corresponding to the cwd and then could match against the
> configured list to decide whether to return early.

That would be a better interface, but the implementation must cope
with colons in paths on Unixes, case insensitive file systems, and
different path representations on Windows (C:\path\to\repo vs.
/c/PaTh/To/RePo).  I'm not sure we want to go there.

Gábor

Re: [PATCH] bash prompt: add option to disable for a repository

[Johannes Sixt]

Am 11/26/2013 0:43, schrieb Jonathan Nieder:
> Heikki Hokkanen wrote:
> 
>> If running git config on each prompt seems too expensive, do you have
>> any better ideas?
> 
> Perhaps a GIT_PS1_NOT_FOR_THESE_REPOS=repo1:repo2:repo3 setting would
> work.

Yeah, but... I find the wish to show the bash prompt in some, but not all,
repositories so uncommon that I doubt that it must be a feature of
__git_ps1. There can be a wrapper function that does the repository
discovery and calls into __git_ps1 as needed. No current __git_ps1 users
need to be burdened.

-- Hannes

Re: [PATCH] bash prompt: add option to disable for a repository

[Thomas Rast]

Heikki Hokkanen <hoxu@users.sf.net> writes:

> On Sat, Nov 23, 2013 at 4:42 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> Gah! This adds a fork+exec each time the prompt is shown. Not good,
>> particularly on Windows.
>>
>> Since your intent is to disable the prompt in the home directory,
>> wouldn't that mean that most of the time you *don't* want the prompt?
>> Wouldn't you be better served with a method that *turns on* the prompt?
>> For example, a shell function that sets PS1 and another one that unsets
>> it? Or a wrapper that inspects a shell variable and calls __git_ps1 only
>> when you want a prompt.
>
> Actually, I do want the prompt for all other git repositories. The
> problem with $HOME is that it's the default directory after logging in
> or opening a terminal, so if you have git prompt sourced and your
> $HOME under git, you get an unbearable delay every time you open a
> terminal, or type a command, anywhere, except for a separate git
> repository.

Umm... is __git_ps1 by itself so slow that you find it unbearable, or is
it the worktree status discovery?  Because the latter can already be
controlled per repository via bash.showUntrackedFiles and
bash.showUpstream.

-- 
Thomas Rast
tr@thomasrast.ch