On Wed, Mar 20, 2013 at 07:36:41PM +0100, Fredrik Gustafsson wrote:
> > Yes, I would certainly like my git startup time to be improved. But I
> > don't want to trade my hard drive's life for it.
>
> Does this really increase disk-reads? The fs-cache would make sure that
> the disk reads is almost the same, we only do them before we usually do
> them.
It shouldn't. But if you are running "stat" on every file in the repo
for each prompt, that is going to take measurable CPU time for large
repos (e.g., WebKit).
> > What I meant by "first time" is "chpwd() into the git repository, not
> > further chpwd()s when already inside the git repository".
>
> That's a good point. I'm not sure how to solve that though. Because it's
> not a fact that you always go to the root git-dir first.
>
> The only way I see this is with a lock-file that's kept and we only run
> git status every 5 minutes when doing something inside a work dir. That
> would add a lot of meta-data (the lock files), to store. (I hope I
> successfully explained that).
How about something like:
__git_primed_toplevel=
__git_prime_dir() {
local toplevel=`git rev-parse --show-toplevel 2>/dev/null`
if test -n "$toplevel" &&
test "$toplevel" != "$git_primed_toplevel"; then
git status >/dev/null 2>&1
git_primed_toplevel=$toplevel
fi
}
that would prime the whole repo the first time you enter it, but otherwise do
nothing (and you could run it from each prompt). If you switched back and forth
between two repos a lot, you would end up priming them both a lot, but that is
not that common a mode of operation (and you could keep an list of recently
primed repos instead of a single one, if you really wanted to deal with that).
You would also prime twice if you used two different terminals, but that's OK.
The subsequent ones are much faster due to disk cache, so this is really just
about not paying the extra stat penalty on _every_ prompt.
-Peff
--
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