Re: Unresolved issues

> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> On Mon, 19 Feb 2007, Junio C Hamano wrote:
>>
>>> * "git fetch" between repositories with hundreds of refs.
>>>
>>> 	$gmane/39330
>>>
>>>  There are partial rewrite of the most expensive parts of git-fetch in
>>>  C parked in 'pu'.  It might be good enough for public consumption
>>>  without going the whole nine yards.  I dunno.  I am not very keen on
>>>  rewriting all of "git fetch" in C right now, as people seem to be
>>>  still interested in touching it (including "git bundle" topic).
>>
>> The current changes in jc/fetch take things from "unusable" to "a bit
>> slow", which I think could quite easily be considered a separate task
>> from "a bit slow" to "something that even Linus would consider
>> reasonable".  So my opinion would be to get the current improvements
>> in so that they can be combined with the other good work happening in
>> this area, and wait for things to settle before going the last mile
>> (after all anyone converting from Subversion or CVS probably won't
>> find 30s to be slow anyway ... ;)).
>
> I was kind of waiting for dust from Santi's code shuffling to
> settle down, because the series moderately conflicts with it.  I
> wanted to take Santi's patch first as it was supposed to be a
> clean-up without any functionality changes, although it was kind
> of painful to really make sure there is no regression.

>
> If what jc/fetch topic tries to do helps real users, let's merge
> it in 'next' first, as Santi's change is not supposed to bring
> any improvements by itself even when it proves regression-free.
>
> In the short term, this means we have to ask Santi to rebase his
> patch instead of the other way around as I planned first, which
> is a bit unfortunate.