Any progress on fixing this?
I'll report that with git version 1.5.4.3.447.gc95b3.dirty
(just a couple days old) I've observed this when updating
a clone by pulling from
(a) a parent on the same disk partition
(b) a parent on a non-mirrored network server
So that would seem to trash the assumptions that this is
related to version mismatch between mirrors, and that the
fix can (or should!) wait till 1.6.0 ...
I was glad to see the "^C" workaround, that seems to work.
When I "git pull" it first fetches a bunch of files, then
concludes (wrongly) "no common commits", then starts a
second fetch of a *HUGE* number of files ... 400 MB is too
much to pay when updating from rc3-last-week to rc4. But
if I interrupt that second one with ^C, it seems that the
first one fetched enough to make the next "git pull" go
pretty quickly.
This does seem appear to show up more often lately because
of RC4 having been tagged ... but I don't know for sure.
I've got a couple kernel workspaces still on last Friday's
version, which -- if this holds true to form! -- will show
this bug when I "git pull". So if there are experiments
that would help nail down what's going on here, please
spell them out to me ("this command, then this ... send
this output...").
- Dave
--
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
