Re: What's cooking in git.git (topics)

"Santi Béjar" [off-list ref] writes:

quoted

I tried the "NULL fetch between 1000-refs repositories" test,
which prompted the git-fetch--tool work that was done on
jc/fetch topic in 'next', with the following versions:

 (1) 1.5.0 (without any git-fetch--tool optimization)
 (2) master (ditto)
 (3) master with jc/fetch (but not sb/fetch topic)
 (4) next ((3) plus sb/fetch and others)

The test scripts are at the end of this message.  Both (1) and
(2) take 3 minutes 7 seconds wallclock time.  (3) improves it
down to 15 seconds.  (4) makes the operation spend 24 seconds
(the times are all on my primary machine x86-64 with 1GB, hot
cache and average of three runs each).

I think it is not fair,...

That's a very unexpected response.  I personally do not think
the separation of FETCH_FETCHED made improvements to the code,
but the above numbers do not have anything to do with such
perhaps subjective ascetic judgement.

The comparison showed that the "Split" patch is a step backward
from the existing optimization hack that was specifically made
to solve an issue raised on the list, and you may not like the
numbers, but if you call that is "not fair", I do not know what
could be considered fair.

Yes, life is unfair, but I do not think that word applies to
this particular case.