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