Carl WorthSomebody 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