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

From: Heikki Hokkanen <hoxu@users.sf.net>
Date: Nov 25, 2013, 16:38 UTC
Message-ID: <CAOpY_XvKkdU+2uxj3K4ZgTq+6qniLYH=bwbQZ6jyrDM7+dZAxg@mail.gmail.com>
In-Reply-To: <20131123163559.GB13824@goldbirke>

Hello,

On Sat, Nov 23, 2013 at 6:35 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:

Show 10 quoted lines

> 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