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