Re: Unresolved issues

From: Junio C Hamano <junkio@cox.net>
Date: Feb 26, 2007, 03:39 UTC
Message-ID: <7vtzx9oaeb.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0702260112160.12555@beast.quantumfyre.co.uk>

Julian Phillips <julian@quantumfyre.co.uk> writes:

Show 20 quoted lines

> 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.