Re: Git is not scalable with too many refs/*

A coworker of mine pointed out to me that a simple

  git checkout 

can also take rather long periods of time > 3 mins when run on a repo with ~100K refs.

While this is not massive like the other problem I reported, it still seems like it is more than one would expect. So, I tried an older version of git, and to my surprise/delight, it was much faster (.2s). So, I bisected this issue also, and it seems that the "offending" commit is 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07:

commit 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07
Author: Christian Couder <chriscool@tuxfamily.org>
Date:   Fri Jan 23 10:06:53 2009 +0100

    replace_object: add mechanism to replace objects found 
in "refs/replace/"

    The code implementing this mechanism has been copied 
more-or-less
    from the commit graft code.

    This mechanism is used in "read_sha1_file". sha1 passed 
to this
    function that match a ref name in "refs/replace/" are 
replaced by
    the sha1 that has been read in the ref.

    We "die" if the replacement recursion depth is too high 
or if we
    can't read the replacement object.

    Signed-off-by: Christian Couder 
<chriscool@tuxfamily.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

Now, I suspect this commit is desirable, but I was hoping that perhaps a look at it might inspire someone to find an obvious problem with it.

Thanks,

-Martin