On Sun, 30 Dec 2007, Grégoire Barbier wrote:
> Hi everybody.
>
> I've just subscribed to the list, therefore I think it should be rude not to
> introduce myself. My name is Grégoire Barbier (non french-speaking people
> should call me Greg and don't bother with non-ascii characters), I'm working
> mainly as a consultant (using Powerpoint and wearing a tie) but have some
> personal and professional interest in programming, especially about
> middlewares. BTW I apologize for my poor english.
>
> I'm using Git for a rather short time but enough to fall in love with it. For
> a few days I'm trying to use it over webdav, that is over http/https with
> write (push) access. As for me, the main rationale to use http(s) rather than
> git or ssh is to get through corporate firewalls, otherwise I would probably
> not bother with webdav.
In general, we've been able to either get through firewalls with ssh or
it's all in the same VPN. So it's kind of unloved at this point. People
poke at it occasionally, but mostly in the context of other fixes, I
think.
> With 1.5.3.6 and 1.5.4-rc2, I encounter severe issues that make me think that
> http-push is not totally ready for production. That's why I would like to have
> a discussion with some of you that use and maintain it, to see what I can do
> to improve it or to help you improve it.
>
> Here are some issues I encountered:
> - http-push does not release locks when failing due to syntax error (e.g. if
> one types "git push" instead of "git push origin master")
> - http-push freezes with no message with urls not terminated by a slash
> - http-push does not create directory for the object (objects/xx/) and if the
> directory exists, it does not actually push objects without having
> USE_CURL_MULTI defined (which is not the compilation default)
>
> I've starting to look at the source code and make some little improvements,
> but I feel that I should rather discuss with you to understand why there are
> two rather independant modes in http-push (USE_CURL_MULTI or not) and what is
> the real target (I don't want to work twice, neither to mess up the work of
> someone else that would be currently reorginzing this part of the code).
I think the issue is the CURL_MULTI library code is either not supported
or is broken in versions of curl that many distros still ship, but we can
do a lot better with it, so the duplicate implementation is plausibly
worthwhile.
One thing I personally thought would be worthwhile would be to separate
out the logic for sending stuff like the fetching logic is in
walker.{c,h}, and include the necessary methods in struct walker. There
were people interested in sftp (for the case where you can get ssh through
firewalls, but you aren't allowed to install programs on the file server
and git isn't installed system-wide).
One thing that's worth doing when looking at the code is using "git blame"
to find out where the lines you're changing came from, and "git log
<hash>" to find out what the person writing them was trying to do. This
will also turn up the people who've been working in the area, who you
might want to cc, since they'll be good reviewers.
-Daniel
*This .sig left intentionally blank*
