Re: GIT push to sftp (feature request)

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Aug 6, 2007, 00:00 UTC
Message-ID: <46a038f90708051700t7a758f8fwdf7c63c8aeef9ee8@mail.gmail.com>
In-Reply-To: <vpqir7t8vy0.fsf@bauges.imag.fr>

On 8/6/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

Show 10 quoted lines

> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > Git tries to be smart in at least 2 ways that don't work with dump
> > protocols: it works locklessly (yet it performs atomic updates) and it
> > sends only the objects needed over the wire (saving a lot of
> > bandwidth).
> >
> > Using dumb protocols it's impossible to do either.
>
> That's not exactly true. You can't be as efficient with dumb protocols

You are right -- I should have said: it's pretty hard, and we haven't put the effort ;-)

there's been discussion recently of having info in the pack index that would support http range requests.

> (its ancestor,
> GNU Arch, also had a way to be network-efficient on dumb protocols).

Do I remember your name from gnuarch-users? -- that Arch/tla was never particularly efficient, and fetches of large updates were slow and painful. Surely it was efficient on paper though :-p

> Regarding atomic and lock-less updates, I believe this is
> implementable too as soon as you have an atomit "rename" in the
> protocol. But here, bzr isn't a proof of existance, it does locking.

And I should have said - minimal locking rather than no locking

To update it safely, you need to open with a lock, read to ensure the sha1 is what you think it is, write the new sha1, close. A rename is still subject to race conditions.

IMVHO it would be good to have a way to push over sftp even it it is slow, unsafe and full of big blinking warnings. git itself is sane enough that the client side won't get corrupted or lose data if there is a race condition on the server side.

Given a brief delay, the client can probably check - post push - that the operation wasn't clobbered by a race condition. Of course, this *is* sticks-and-bubblegum approach on the server side. But a solid client repo makes almost any server-side disaster recoverable.

cheers,

martin