Re: [PATCH 14/14] clone: give advice on how to resume a failed clone

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 10, 2011, 21:21 UTC
Message-ID: <7vvcqrsmfx.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20111110075654.GN27950@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

> We could make "git clone ..." automatically resume, but I'm a little
> nervous about that. I wrote a patch that did so, and it did work, but
> there are a lot of little hiccups as we violate the assumption that the
> directory didn't already exist (e.g., it writes multiple fetch refspec
> lines to the config).

Sorry, but I do not think the worry is quite justified.

The "assumption that directory didn't already exist" becomes an issue only if you implement your "git clone" that automatically resumes as a thin wrapper around the current "git clone" in the form of

    until git clone ...
    do
	echo retrying...
    done

Stepping back a bit, I think there are two different situations where resumable clone is beneficial. The "git clone" process died either by the machine crashing or the user hitting a \C-c, or the connection between the server and the "git clone" got severed for some reason.

Right now, the "got disconnected" case results in "git clone" voluntarily dying and as the result of this, the symptom appears the same. But it does not have to be that way. If we know the underlying transport is resumable, e.g. when you are fetching a prepared bundle over the wire.

I have this suspicion that in practice the "got disconnected" case is the majority. If "git clone" does not die upon disconnect while fetching a bundle, but instead the fetching of the bundle is resumed internally by reconnecting to the server and requesting a range transfer, there is no risk of "writes multiple fetch refspec lines" etc, no?

Of course, it is _also_ beneficial if we made "git clone" resumable after you purposefully kill it (maybe you thought it will clone within minutes, but it turns out that it may take hours and you have to turn off the machine in the next five minutes before leaving the work, or something). A solution for that case _could_ be used for the "got disconnected" case by letting it voluntarily die as we currently do, but I do not think that is an optimal solution to the "got disconnected" case.