Fredrik Gustafsson wrote:
> On Wed, Mar 20, 2013 at 10:45:22PM +0530, Ramkumar Ramachandra wrote:
>> Fredrik Gustafsson wrote:
>> > When entering a git working dir, optionally run a forked process that
>> > stat all files in the whole workdir and therefore loads stat information
>> > to RAM which will speedup things like git status and so on.
>> This is misleading. You just execute the equivalent of `git status`
>> everytime I request a prompt inside a git working directory. And this
>> is if I'm using __git_ps1() to augment my prompt, which I'm not- I use
>> ZSH's vcs_info, which is arguably better. Also, you forgot to say how
>> to turn on the feature.
> The invokation place is quesionable (Junio also had some thoughts about
> that). I don't find vcs_info in the contrib/completition/. Do you have
> any suggestion about where the best way is to inwoke this kind of thing?
I think it should be a separate script in contrib/ that people can
just `eval` in their shell configs; zsh has a chpwd() function for
example, which seems like the right place to put such a thing.
> I added documentation about how to turn the feature on, in the same way
> the other features is documented. (Is there an other way/better way I
> should do this?)
No, I meant in the commit message.
>> That said, this feature is extremely gross; it thrashes my filesystem
>> and hard drive. Modern software is written to minimize IO, not
>> maximize it! I'm completely against the inclusion of this patch.
> It's extremly gross. I don't like this, _but_ it does speed up my work.
> I'm unsure if it should be included in git though (hence the RFC-tag).
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.
>> However, I would not mind a feature that runs `git status` the very
>> first time I enter a git working directory: when I enter my clone of
>> linux.git, it takes my first `git status` invocation a good ten
>> seconds to complete, and we can fix this pretty easily.
> That's the problem I try to solve. However "the first time" is
> irrelevant. We will run git status a bit before we need it. If we enter
> linux.git, do other work (in an other project) for an hour and go back
> to linux.git our cache will probably be empty. We will need to run this
> more than "the first time". But still, we don't want it to run too
> often. (Which is does now).
What I meant by "first time" is "chpwd() into the git repository, not
further chpwd()s when already inside the git repository".
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