git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Andy Parkins <andyparkins@gmail.com>, git@vger.kernel.org
Subject: Re: git-status and git-diff now very slow in project with a submodule
Date: Fri, 21 May 2010 14:05:36 +0200	[thread overview]
Message-ID: <4BF67710.30805@web.de> (raw)
In-Reply-To: <7vbpca6uxi.fsf@alter.siamese.dyndns.org>

Am 21.05.2010 00:59, schrieb Junio C Hamano:
> At least we should be able to let the users say, with "git status -uno",
> "I don't care about untracked and unignored paths; I don't make such a
> mistake to forget adding new paths", and optimize the scanning of
> submodule directories taking advantage of that statement.  Is there a
> fundamental reason why things shouldn't work that way, or is it just a
> bug in the current code?

It works that way since 3bfc450. "git status" (and the diff family when
comparing against the work tree) forks a "git status" for each submodule
that is populated. If the status command in the superproject is started
with "-uno" the same option is used for the "git status" forked in the
populated submodules, so no checking for untracked files is done in that
case.

But that doesn't speed up that process much, as the tracked files inside
the submodules have to be checked for modifications anyway, no matter if
"-uno" is used or not. Getting rid of the fork of a new "git status" by
using an alternate odb is on my to do list. Apart from gaining some time
by avoiding the fork (which is a per-submodule-constant) we could terminate
early in case we find a modification (instead of continuing as the current
approach does). But only dirty submodules would profit from that, a clean
submodule won't be scanned much faster that way AFAICS.

  reply	other threads:[~2010-05-21 12:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-20 10:01 git-status and git-diff now very slow in project with a submodule Andy Parkins
2010-05-20 10:10 ` Stefan Naewe
2010-05-20 11:37   ` Andy Parkins
2010-05-20 15:52     ` Michael J Gruber
2010-05-20 17:45       ` Andy Parkins
2010-05-20 17:49         ` Jens Lehmann
2010-05-20 18:01           ` Andy Parkins
2010-05-21 12:36             ` Nguyen Thai Ngoc Duy
2010-05-20 13:28 ` Junio C Hamano
2010-05-20 17:17   ` Andy Parkins
2010-05-20 22:59     ` Junio C Hamano
2010-05-21 12:05       ` Jens Lehmann [this message]
2010-05-21 12:52   ` Leo Razoumov
2010-05-21 17:54     ` Andreas Schwab
2010-05-22 12:05       ` Jens Lehmann
2010-05-22 12:08     ` Jens Lehmann

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=4BF67710.30805@web.de \
    --to=jens.lehmann@web.de \
    --cc=andyparkins@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).