Re: dumb transports not being welcomed..

From: Jon Loeliger <jdl@freescale.com>
Date: Sep 14, 2005, 19:13 UTC
Message-ID: <1126725206.14036.22.camel@cashmere.sps.mot.com>
In-Reply-To: <7vk6hjiiew.fsf@assigned-by-dhcp.cox.net>

On Wed, 2005-09-14 at 14:00, Junio C Hamano wrote:

Show 12 quoted lines

> Fair enough.  My excuse is that Linus did not want the
> update-server-info hook enabled by default.  He does not believe
> in dumb transports anyway, but aside from that, it still is a
> valid attitude because it is not necessary when you do not
> intend to publish your repository over dumb transport at all but
> still want to push into it.  And another excuse is I do not
> in general think enabling hooks by default is a good idea.
> 
> Even if you built your repository with older git tools, you
> should be always able to say 'GIT_DIR=that-repository
> git-init-db' without damaging its existing contents to install
> the disabled hooks in its hooks/ directory.

Hmmm. Maybe this is all begging a form of documentation down the "Best Practices" line, or "Tips I Learned By Reading Junio and Linus Postings on Git". :-)

> And I thought rsync was a reliable way too, until I saw a
> message from Tony Luck this morning X-<.

Heh. I read his problem description too, and it sounded remarkably close to the HTTP pull problems that I had been victimized by, thus converting me to rsync (for now).

I have recloned entire repos due to the aborted pulls being left in an inconsistent state. In fact, that is what lead me to find git-fsck-cache, which I was expecting to sort out the missing pieces and detect an incomplete clone. Perhaps marking it as "needing completion" via another clone/pull effort. Dunno.

jdl