Woohoo! The stuff you moved to master (which is what I was building
from, not "next", as Nick pointed out) has fixed the git-http-fetch
segfault problem I was seeing.
Thanks!
-Becky
On Jun 2, 2006, at 12:38 PM, Junio C Hamano wrote:
Junio C Hamano <junkio@xxxxxxx> writes:
Nick Hengeveld <nickh@xxxxxxxxxxxx> writes:
- "git push" seems to pass --thin by default to http-push, which
subsequently barfs because that's not a valid http-push option.
Should it be? Should it be silently ignored? Should git-push not
default to --thin when pushing with HTTP transport?
The way I understand http-push works is that it does not use
packed transfer, so I presume even if we give --thin as a hint
it cannot even take advantage of it. Probably we should stop
passing --thin to http transport (git native one uses it as a
cue that it can generate baseless deltas in the resulting pack).
- when I clone, http-fetch outputs a whole bunch of
"error: Could not read ..." messages - is that expected?
The clone over http seems to be severely broken in "next" right
now. The one in "master" seems to be OK. bisecting suggests
the breakage is coming from the tree parser rewrite.
bisect points at 136f2e548a34f1f504b0f062f87ddf33e8d6e83b.
I've pushed out Nick's http-fetch fixes in "master" to see if it
fixes problems for people. Right now the one in "next" branch
seems to be having unrelated problems coming from another topic
which I haven't started tracking down yet.
-
: 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