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

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

Hi,

On Fri, Feb 19, 2010 at 6:26 PM, Fabien <fabien.ubuntu@gmail.com> wrote:

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.

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.

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

You said it yourself. :)

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

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

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.

On Fri, Feb 19, 2010 at 11:26:16AM +0100, Fabien 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).

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

-Ilari

Ilari Liusvaara wrote:

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

On Fri, Feb 19, 2010 at 7:08 AM, Fabien <fabien.ubuntu@gmail.com> wrote:

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.