On Thu, Mar 21, 2013 at 10:44 AM, Junio C Hamano wrote:
> Thomas Rast writes:
>
>> I think it would actually be a somewhat interesting feature if it
>> interacted with GIT_PS1_SHOW*. If you use these settings (I personally
>> use SHOWDIRTYSTATE but not SHOWUNTRACKEDFILES), the prompt hangs while
Thomas Rast writes:
> I think it would actually be a somewhat interesting feature if it
> interacted with GIT_PS1_SHOW*. If you use these settings (I personally
> use SHOWDIRTYSTATE but not SHOWUNTRACKEDFILES), the prompt hangs while
> __git_ps1 runs git-status. It should be possible to run a g
Jeff King writes:
> On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > So maybe just run "git status >/dev/null"?
>>
>> In the background? How often would it run? I do not think a single
>> lockfile solves anything. It may prevent simultaneous run
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 almos
On Wed, Mar 20, 2013 at 12:48:06PM -0400, Jeff King wrote:
> Kind of gross, but I guess it is useful to some people.
Yes it is. The questions is if it's gross enough to never
leave my computer, or if someone else can find this useful.
>
> > +__git_recursive_stat ()
> > +{
> > + if test ! -e /t
On Wed, Mar 20, 2013 at 11:19:38PM +0530, Ramkumar Ramachandra wrote:
> 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 was trying to spare the
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 w
On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So maybe just run "git status >/dev/null"?
>
> In the background? How often would it run? I do not think a single
> lockfile solves anything. It may prevent simultaneous runs of two
> such "prime the we
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 stat
Jeff King writes:
> So maybe just run "git status >/dev/null"?
In the background? How often would it run? I do not think a single
lockfile solves anything. It may prevent simultaneous runs of two
such "prime the well" processes, but the same user may be working in
two separate repositories.
On Wed, Mar 20, 2013 at 01:15:32PM +0100, 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.
>
> The feature is o
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.
The feature is optional and by default it's off.
Signed-off-by: Fredrik Gustafsson
---
contr
12 matches
Mail list logo
