On Thu, Mar 21, 2013 at 10:44 AM, Junio C Hamano gits...@pobox.com wrote:
Thomas Rast tr...@student.ethz.ch 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
Jeff King p...@peff.net writes:
On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Thomas Rast tr...@student.ethz.ch 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
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
Jeff King p...@peff.net 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
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
On Wed, Mar 20, 2013 at 10:15:39AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
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
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
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
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
11 matches
Mail list logo
