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

On Mon, 26 Sep 2011 20:34:02 -0600, Martin Fick wrote:

quoted

Julian Phillips [off-list ref] wrote:
On Mon, 26 Sep 2011 18:12:31 -0600, Martin Fick wrote:
That sounds a lot better.  Hopefully other commands should be faster
now too.

Yeah, I will try this in a few other places to see.

quoted

quoted

Thanks way much!!!

No problem.  Thank you for all the time you've put in to help chase
this down.  Makes it so much easier when the person with original
problem mucks in with the investigation.
Just think how much time you've saved for anyone with a large number 
of

those Gerrit change refs ;)

 Perhaps this is a naive question, but why are all these refs being
put into a list to be sorted, only to be discarded soon thereafter
anyway?  After all, git branch knows that it isn't going to print
these, and the refs are stored precategorized, so why not only grab
the refs which matter upfront?

I can't say that I am aware of a specific decision having been taken on 
the subject, but I'll have a guess at the reason:

The extra code it would take to have an API for getting a list of only 
a subset of the refs has never been considered worth the cost.  It would 
take effort to implement, test and maintain - and it would have to be 
done separately for packed and unpacked cases to avoid still loading and 
discarding unwanted refs.  All that to not do something that no-one has 
noticed taking any time?  Until now, I doubt anyone has considered it 
something that was a problem - and now that even with 100k refs it takes 
less than a second, I doubt anyone will feel all that inclined to have a 
crack at it now either.

-- 
Julian