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@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
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
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
--
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