On Sun, 25 Feb 2007, Junio C Hamano wrote:
Julian Phillips <julian@xxxxxxxxxxxxxxxxx> 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.
Indeed. I was thinking pretty much the same. It seems unnecessary to
make Santi rebase his patch without any evidence that the jc/fetch topic
is actually urgently needed by anyone.
I was advocating a two step approach, but I didn't mean to give the
impressions that I wanted the topic merged now. I envisioned both steps
as being after the current active work that is affecting git-fetch.
Thanks to the power of git I have got myself a master+jc/fetch branch so
I'm happy - so unless there is anyone else out there working with stupidly
large numbers of refs I'm quite happy to let Santi's work go in first.
I'll even have a go at rebasing the fetch improvements ontop of Santi's
work ...
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.
Unless there is someone else out there that wants jc/fetch badly, I would
say "after you" ...
--
Julian
---
This report is filled with omissions.
-
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