git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fredrik Gustafsson <iveqy@iveqy.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Fredrik Gustafsson <iveqy@iveqy.com>,
	spearce@spearce.org, git@vger.kernel.org, pclouds@gmail.com,
	Jeff King <peff@peff.net>
Subject: Re: [RFC] Add posibility to preload stat information.
Date: Wed, 20 Mar 2013 19:36:41 +0100	[thread overview]
Message-ID: <20130320183641.GB32426@paksenarrion.iveqy.com> (raw)
In-Reply-To: <CALkWK0nCY3o_KW8ykq9TkzfHeVj6NKDkOFuym9UmSWLH0ZFxBw@mail.gmail.com>

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 number of calls to "git rev-parse
--is-inside-work-tree". But maybe that is to fast to care about.

> No, I meant in the commit message.

Okay, thanks.

> >> 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.

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.

> 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).

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

  reply	other threads:[~2013-03-20 18:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 12:15 [RFC] Add posibility to preload stat information Fredrik Gustafsson
2013-03-20 16:48 ` Jeff King
2013-03-20 17:15   ` Junio C Hamano
2013-03-20 17:47     ` Jeff King
2013-03-21 10:41       ` Thomas Rast
2013-03-21 14:44         ` Junio C Hamano
2013-03-30 19:42           ` Phil Hord
2013-03-20 18:40   ` Fredrik Gustafsson
2013-03-20 17:15 ` Ramkumar Ramachandra
2013-03-20 17:41   ` Fredrik Gustafsson
2013-03-20 17:49     ` Ramkumar Ramachandra
2013-03-20 18:36       ` Fredrik Gustafsson [this message]
2013-03-20 18:46         ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130320183641.GB32426@paksenarrion.iveqy.com \
    --to=iveqy@iveqy.com \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).