All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: Philippe Vaucher <philippe.vaucher@gmail.com>
Cc: Duy Nguyen <pclouds@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Christian Jaeger <chrjae@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: git gc --aggressive led to about 40 times slower "git log --raw"
Date: Wed, 19 Feb 2014 10:01:08 +0100	[thread overview]
Message-ID: <87bny3qxwr.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <CAGK7Mr4wpwUK6UF6vTmgszX4sajPDvQazY2QagFfH9BEJx_9Ow@mail.gmail.com> (Philippe Vaucher's message of "Wed, 19 Feb 2014 09:38:31 +0100")

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>> fwiw this is the thread that added --depth=250
>>
>> http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626
>
> This post is quite interesting:
> http://article.gmane.org/gmane.comp.gcc.devel/94637

Yes.  Of course I am prejudiced because I volunteered fixing git-blame
on the Emacs developer list in order to make it more feasible to
transfer the Emacs repository to Git.

Calling git blame via C-x v g is a rather important part of the
workflow, and it's currently intolerable to work with on a number of
files.

While I'm fixing the basic shortcomings in builtin/blame.c itself, the
operation "fetch the objects" is necessary for all objects at least
once.  It's conceivable that some nice caching strategy would help with
avoiding the repeated traversal of long delta chain tails.  That could
also help defusing the operation of basic stuff like git-log.

But the short and long end of it is that there are valid operations
accessing a large amount of past history, and one point of having a
distributed version control system with non-shallow repository by
default is to have history and ways of working with it at one's hand.

And git's default modus of operation is _not_ to store things like
copies and moves and renames in commits, but deduce them from looking at
the stored data.  So making looking at stored data including old data
expensive means that Git does not work well in the way it is designed to
operate.

-- 
David Kastrup

  reply	other threads:[~2014-02-19  9:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18  7:25 git gc --aggressive led to about 40 times slower "git log --raw" Christian Jaeger
2014-02-18  8:55 ` David Kastrup
2014-02-18  9:45   ` Duy Nguyen
2014-02-18 10:25     ` David Kastrup
2014-02-18 15:59       ` Jonathan Nieder
2014-02-18 20:59         ` Junio C Hamano
2014-02-18 22:46           ` Duy Nguyen
2014-02-19  0:10             ` Junio C Hamano
2014-02-19  0:33               ` Duy Nguyen
2014-02-19  8:38                 ` Philippe Vaucher
2014-02-19  9:01                   ` David Kastrup [this message]
2014-02-19 10:24                     ` Duy Nguyen
2014-02-19 10:14                   ` Duy Nguyen
2014-02-20  4:09                     ` Christian Jaeger
2014-02-20 16:48                     ` David Kastrup
2014-02-20 17:06                       ` David Kastrup
2014-02-20 18:07                         ` David Kastrup
2014-02-19 18:59                   ` Junio C Hamano
2014-02-20 23:35                     ` Duy Nguyen
2014-02-21  0:32                       ` Christian Jaeger
2014-02-21 17:36                         ` Junio C Hamano
2014-02-21  5:09                       ` Duy Nguyen
2014-02-21 17:47                       ` Junio C Hamano
2014-02-24  9:27                         ` Philippe Vaucher
2014-02-22  0:36           ` Duy Nguyen
2014-02-22  6:20             ` David Kastrup
2014-02-22  8:53               ` David Kastrup
2014-02-22  9:14                 ` Duy Nguyen
2014-02-22 13:00                   ` Duy Nguyen
2014-02-22  9:57               ` Andreas Schwab
2014-02-18 16:43     ` Christian Jaeger

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=87bny3qxwr.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=chrjae@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=philippe.vaucher@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.