I seem to be having a problem doing an http checkout with git built

with curl 7.16.0 enabled.  If I build against curl 7.16.0 and try a

clone, I get:
git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git

error: Unable to start request error: Could not interpret heads/master

as something to pull
If I rebuild git against curl 7.15.5 then I get:

git clone

http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git got

9a985de4a4cfa973a4573828df4cbb2e4f66c419 walk

9a985de4a4cfa973a4573828df4cbb2e4f66c419 got

c431dee75dfadb4c6f81bd95fa1ae44b2b07b359 got

6e645158ba349eaa68caa4c37d18412b30bfd76d walk

c431dee75dfadb4c6f81bd95fa1ae44b2b07b359 got

e452f63c2af324254b7f65f955cbb5ac8efa6762 got
and the checkout finishes.
Has any one else seen this?
George Sherwood

Lead Developer Sourcemage GNU/Linux

http://www.sourcemage.org

-

FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.

It worked fine with curl 7.15.0.
skimo

-

It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while

it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.
Furthermore, with new curl pulling from HTTP repos when there are updates

gives double free errors and a crash.

--

Dr. Horst H. von Brand                   User #22616 counter.li.org

Departamento de Informatica                    Fono: +56 32 2654431

Universidad Tecnica Federico Santa Maria             +56 32 2654239

Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513
-

Hmmm.  Could somebody please run http-fetch under gdb and see

where it breaks?  The exact command line you need to use would

be obtainable by running "sh -x git-clone" once.
[jc: Nick CC'ed, although I haven't seen him on the list for

some time...]
-

It crashes the kernel for me here :-(
I tried to chop down a tig repo a few commits from the top for checking out

the crash I'm seeing (only when pulling from a remote repo by HTTP, and it

is not up to date here) by doing:
  cp -r tig tig.tst

  cd tig.tst

  git reset --hard HEAD~3

  git prune
But now git-pull /doesn't/ fetch anything, so I see no crash. What am I

doing wrong here?

--

Dr. Horst H. von Brand                   User #22616 counter.li.org

Departamento de Informatica                    Fono: +56 32 2654431

Universidad Tecnica Federico Santa Maria             +56 32 2654239

Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

-

Another ref points at the same commit as what ORIG_HEAD points at,

so there wasn't anything to fetch as you already had that commit.
Its probably a tag, a ref under refs/remotes, or another branch...
--

Shawn.

-

When we do not have NO_CURL_EASY_DUPHANDLE defined, http.c

prepares a single "CURL *curl_default" with get_curl_handle(),

and new request slots clone it using curl_easy_duphandle().

However, the returned "clone" somehow forgets to set the "magic"

number that says it is a GOOD_EASY_HANDLE().  This missing magic

number is checked by cURL library in curl_multi_add_handle(),

which we call from start_active_slot().  Hence the request

fails.
Now, I do not know cURL, and cannot tell if it is just a bug in

easy-duphandle of curl 7.16.0, or if we are not supposed to be

using the "easy" interface when dealing with multi fetch.  In

either case, the attached patch seems to fix it for me.
I am NOT CC'ing curl-library@cool.haxx.se mailing list since I

do not want to subscribe only to be able to post, but some kind

souls who are subscribers could forward the issue to them to

determine if we need to fix our code (and if so how), or if we

need to wait for them to fix curl_easy_duphandle().
-- >8 --
diff --git a/http.h b/http.h

index 6e12e41..70b18dd 100644

--- a/http.h

+++ b/http.h

@@ -18,7 +18,7 @@

 #define curl_global_init(a) do { /* nothing */ } while(0)

 #endif
-#if LIBCURL_VERSION_NUM < 0x070c04

+#if 1 || (LIBCURL_VERSION_NUM < 0x070c04)

 #define NO_CURL_EASY_DUPHANDLE

 #endif
-

It appears that curl_easy_duphandle() from libcurl 7.16.0

returns a curl session handle which fails GOOD_MULTI_HANDLE()

check in curl_multi_add_handle().  This causes fetch_ref() to

fail because start_active_slot() cannot start the request.
For now, check for 7.16.0 to work this issue around.
Signed-off-by: Junio C Hamano <junkio@cox.net>

---
 * I think people who were having trouble with cURL 7.16.0 want

   to have the issue resolved before v1.5.0-rc1.  Please test

   and report, or else ;-).
 http.h |    2 +-

 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/http.h b/http.h

index 6e12e41..324fcf4 100644

--- a/http.h

+++ b/http.h

@@ -18,7 +18,7 @@

 #define curl_global_init(a) do { /* nothing */ } while(0)

 #endif
-#if LIBCURL_VERSION_NUM < 0x070c04

+#if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)

 #define NO_CURL_EASY_DUPHANDLE

 #endif
--

1.5.0.rc0.gf5c587
-

Checked it out. Now clone and pull both work here.
Thanks!

--

Dr. Horst H. von Brand                   User #22616 counter.li.org

Departamento de Informatica                    Fono: +56 32 2654431

Universidad Tecnica Federico Santa Maria             +56 32 2654239

Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

-