Re: git gc --aggressive led to about 40 times slower "git log --raw"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Philippe Vaucher <philippe.vaucher@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]