On Sat, Nov 23, 2013 at 6:35 PM, SZEDER Gábor <sze...@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.


Heikki Hokkanen
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to