On Mon, Jun 03, 2013 at 09:39:21AM +0100, Alex Bennée wrote: > > in the target repository. You can check that it's working because "git > > rev-list --all --count" should be an order of magnitude faster. You may > > need to add "save_commit_buffer = 0" in any commands you are checking, > > though, as the optimization can only kick in if parse_commit does not > > want to save the buffer as a side effect. > > Is this a command line argument? The tools don't seem to think so. If you mean the "save_commit_buffer = 0", no; I mean you would have to insert it somewhere in builtin/$CMD.c, and then recompile. However, git-describe already has it, so it should work. > Anyway it seems to make a marginal difference to my case: I get much better results: $ cd linux-2.6 $ time git --no-pager describe --long --tags HEAD~800 v3.5-6956-gaa0b3b2 real 0m0.261s user 0m0.248s sys 0m0.012s $ git metapack --commits --all $ time git --no-pager describe --long --tags HEAD~800 v3.5-6956-gaa0b3b2 real 0m0.057s user 0m0.032s sys 0m0.024s which implies that your time is being spent elsewhere. That topic wouldn't avoid inflating tag objects from disk. Do you have really big tag objects (or unannotated tags pointing to blobs)? What does: git for-each-ref --format='%(object)' refs/tags | git cat-file --batch-check | sort -k 3nr | head say? -Peff -- 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