Should update-server-info be on by default?

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

Somebody recently handed me an http:// URL for a git repository.
I cloned it and it seemed to work, (got the annoying got/walk spew).
Later I tried to pull down recent changes, but I didn't appear to get
anything new.

Confused, I did a new clone, and found that there were new
changes. And looking closer, I got the following when I did a
git-fetch right after the initial clone:

	Fetching refs/heads/master from	http://www.blaubeermuffin.de/ccc.git using http
	* refs/remotes/origin/master: forcing update to non-fast forward
	branch 'master' of http://www.blaubeermuffin.de/ccc
	  old...new: f5abfee...855b7fa

Here the 'old' was the correct, current contents of the remote
refs/heads/master, but the 'new' was actually the initial commit in
the repository, which is obviously the wrong thing in every way.

And it was easy enough to see that git though that that was the
correct remote head value:

	git ls-remote --heads http://www.blaubeermuffin.de/ccc.git
	855b7fa88a44468754329e795547c968e5d15c7f        refs/heads/master

Now, I'd never actually hit this problem before, but I had heard
rumor of it, so I was able to point the maintainer to the default
.git/hooks/post-update script, and things appear to be working with
that enabled.

My question is, why do we require a hook before a git repository will
function correctly over http protocol? Is whatever this hook does so
expensive that we really shouldn't just do it unconditionally and
avoid all the broken-by-default behavior for dumb protocols?

And if keeping this off by default is really the right thing, can we
detect the problem and actually inform the user about it? Such as, not
let an http: clone function at all until things are setup properly?

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]