Is git over http (git-http-push) ready for production ?

Is git over http (git-http-push) ready for production ?

[Fabien]

Hi,

Following my last email about locks problem with reiserfs (see
git-http-push (git v1.5) problems with DAVLockDB on reiserfs FS), I was
wondering how reliable is git-http-push.

I was able to reproduce the same problem, also with client 1.6.6.2, when
interrupting the command in the middle.

$ git push origin master
Fetching remote heads...
  refs/
  refs/tags/
  refs/heads/
updating 'refs/heads/master'
  from a0f6d85d90a52a28628f29765eb61de559c1fd31
  to   952622ca0f55e76d810a5dc7a1dd1c8c44f8a7d7
Removing remote locks...

=> interrupted by Ctrl+C

$ git push origin master
Fetching remote heads...
  refs/
  refs/tags/
  refs/heads/
updating 'refs/heads/master'
  from a0f6d85d90a52a28628f29765eb61de559c1fd31
  to   952622ca0f55e76d810a5dc7a1dd1c8c44f8a7d7
Unable to lock remote branch refs/heads/master
Updating remote server info
fatal: git-http-push failed


I had to delete the davlock file and restart apache to solve the issue.
So, this operation doesn't seem really atomic ?

Another problem I see is the password in clear text in ~/.netrc to avoid
  to type passwords all the time.
Is there any plan to address this problem ? There used to be the same
case in subversion (yep, sorry for the comparison), and they finally
addressed that by supporting GNOME Keyring and KWallet.
For what I saw, http support is provided thru libcurl, so it may not be
that easy.

Finally, hooks don't work when using git over http (yep, I know, it's a
"dumb" protocol)...

Sorry for blaming you and thanks a lot for your help :)

--
Fabien

Re: Is git over http (git-http-push) ready for production ?

[Tay Ray Chuan]

Hi,

On Fri, Feb 19, 2010 at 6:26 PM, Fabien <fabien.ubuntu@gmail.com> wrote:
> I had to delete the davlock file and restart apache to solve the issue.

I guess this is a regression. Before remote helpers were introduced,
the dumb http-push program was able to release locks on the remote
side on such signals.

> So, this operation doesn't seem really atomic ?

Overall, git-push over dav isn't atomic. At most, it is atomic at the
individual object level - for example, you won't get a blob with SHA-1
"abc123" but hashes to a different SHA-1 value.

> Another problem I see is the password in clear text in ~/.netrc to avoid
>  to type passwords all the time.

Might sound pathetic, but you could chmod it to make it readable only
to yourself.

> Is there any plan to address this problem ? There used to be the same
> case in subversion (yep, sorry for the comparison), and they finally
> addressed that by supporting GNOME Keyring and KWallet.
> For what I saw, http support is provided thru libcurl, so it may not be
> that easy.

You said it yourself. :)

If you really think .netrc isn't your cup of tea, you could tunnel through ssh.

-- 
Cheers,
Ray Chuan

Re: Is git over http (git-http-push) ready for production ?

[Matthieu Moy]

Fabien <fabien.ubuntu@gmail.com> writes:

> Hi,
>
> Following my last email about locks problem with reiserfs (see
> git-http-push (git v1.5) problems with DAVLockDB on reiserfs FS), I was
> wondering how reliable is git-http-push.

My experience is: it mostly works, but sometimes break, usually
doesn't give very helpfull messages when you mis-use it, ...

Rather clearly, git-http-push doesn't have as many users as ssh://,
read-only http:// and git://, and therefore doesn't have as many
testers/developers.

If "production" means "many users" and "need for something
unbreakable", then perhaps the HTTP smart protocol is more promising.

But that's just my experience.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Is git over http (git-http-push) ready for production ?

[Ilari Liusvaara]

On Fri, Feb 19, 2010 at 11:26:16AM +0100, Fabien wrote:
> Hi,
> 
> Following my last email about locks problem with reiserfs (see
> git-http-push (git v1.5) problems with DAVLockDB on reiserfs FS), I was
> wondering how reliable is git-http-push.

> Another problem I see is the password in clear text in ~/.netrc to avoid
>   to type passwords all the time.
> 
> Finally, hooks don't work when using git over http (yep, I know, it's a
> "dumb" protocol)...

1.6.6 introduced Smart HTTP. It is much more efficient, can run hooks and
has same kind of atomicity guarantees as ssh://, but it has few shorcomings:

- Requires server support (CGI script & Git 1.6.6+)
- Hook messages don't work (at least with 1.6.6.X/1.7.0.X)
- Requires 1.6.6+ on client side
- Authentication still sucks (no surprise, auth with HTTP just plain sucks).

But I regard HTTP fetch/push as backup for cases where git:// and ssh://
are not possible.

-Ilari

Re: Is git over http (git-http-push) ready for production ?

[Fabien]

Ilari Liusvaara wrote:
> 1.6.6 introduced Smart HTTP. It is much more efficient, can run hooks and
> has same kind of atomicity guarantees as ssh://, but it has few shorcomings:
> 
> - Requires server support (CGI script & Git 1.6.6+)
> - Hook messages don't work (at least with 1.6.6.X/1.7.0.X)
> - Requires 1.6.6+ on client side
> - Authentication still sucks (no surprise, auth with HTTP just plain sucks).

Ok, thanks ! I wasn't aware of this new feature.
I'll give it a try.
What do you mean by "Hook messages don't work" ?

Thanks.

--
Fabien

Re: Is git over http (git-http-push) ready for production ?

[Shawn Pearce]

On Fri, Feb 19, 2010 at 7:08 AM, Fabien <fabien.ubuntu@gmail.com> wrote:
> Ilari Liusvaara wrote:
>> 1.6.6 introduced Smart HTTP. It is much more efficient, can run hooks and
>> has same kind of atomicity guarantees as ssh://, but it has few shorcomings:
>>
>> - Requires server support (CGI script & Git 1.6.6+)
>> - Hook messages don't work (at least with 1.6.6.X/1.7.0.X)
>> - Requires 1.6.6+ on client side
>> - Authentication still sucks (no surprise, auth with HTTP just plain sucks).
>
> Ok, thanks ! I wasn't aware of this new feature.
> I'll give it a try.
> What do you mean by "Hook messages don't work" ?

Normally over ssh:// output from a hook script is sent to the client's
stderr stream.  This is handled by the SSH connection itself, not by
Git, as SSH has two data channels from server to client (stdout,
stderr).  Under http:// we only have one data stream, so only the git
data that normally goes over stdout gets sent to  the client.  The
hook messages that are sent to stderr wind up in the HTTP server's
error log file.

I've posted patches to multiplex these messages into the git data
stream, but as far as I know, they aren't in a shipping version of Git
yet.