Been beating my head against this for a while:

Here's the problem I have:

$ git submodule init
$ git submodule update
Cloning into contrib/express...
fatal: Unable to find remote helper for 'http'
Clone of 'http://github.com/visionmedia/express.git' into submodule path
'contrib/express' failed


I have git version 1.7.3.1, built from source on FreeBSD 6.4
Prior to building I have curl and expat lib installed.

My git build commands are:
./configure
gmake clean && gmake all
gmake install

I've also tried the configure as follows:
./configure --with-curl=/usr/local --with-expat=/usr/local

in case it was looking elsewhere.  The behaviour I see in this case is
identical.

Philip B.

--

[ message continues ]

Hi Philip,


The "gmake clean" undoes the effect of "./configure".

Hope that helps.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
diff --git a/Makefile b/Makefile
index d3dcfb1..c693652 100644
--- a/Makefile
+++ b/Makefile
@@ -2229,7 +2229,7 @@ dist-doc:
 ### Cleaning rules
 
 distclean: clean
-	$(RM) configure
+	$(RM) configure config.mak.autogen
 
 clean:
 	$(RM) *.o block-sha1/*.o ppc/*.o compat/*.o compat/*/*.o xdiff/*.o vcs-svn/*.o \
@@ -2240,7 +2240,7 @@ clean:
 	$(RM) -r $(dep_dirs)
 	$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h $(ETAGS_TARGET) tags cscope*
 	$(RM) -r autom4te.cache
-	$(RM) config.log config.mak.autogen config.mak.append config.status config.cache
+	$(RM) config.log config.mak.append config.status config.cache
 	$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
 	$(RM) $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
 	$(RM) $(htmldocs).tar.gz $(manpages).tar.gz
--

[ message continues ]

You diagnosed the problem correctly, but I do not think the patch is
correct.  Why should the generated file *.autogen be kept around across
"clean"?

I do understand why we keep "configure" around (it is common for everybody
--

[ message continues ]

Fair enough.  The thought was that most autoconfiscated packages
support

	./configure
	make clean
	make
	make install

since "make clean" does not remove the generated Makefile.  But the
patch was incomplete anyway, since it did not keep config.mak.append

Hmm, isn't the usual scheme something like

 - "make clean" undoes the effect of "make"
 - "make distclean" removes all generated files that are not common
   to everyone
 - "make maintainer-clean" removes all generated files

?
--

[ message continues ]