Re: What's not in 'master' but should be
- From
Mike Hommey <mh@glandium.org>
- Date
- Jan 19, 2008, 06:14 UTC
- Message-ID
- <20080119061421.GA5023@glandium.org>
- In-Reply-To
- <alpine.LSU.1.00.0801181638500.5731@racer.site>
On Fri, Jan 18, 2008 at 06:28:03PM +0000, Johannes Schindelin wrote:
Show 34 quoted lines
> Hi, > > On Fri, 18 Jan 2008, Junio C Hamano wrote: > > > Junio C Hamano <gitster@pobox.com> writes: > > > > > Currently the ones I looked at and consider possible 1.5.4 material > > > are http-push fixes from Grégoire Barbier and parse_commit_buffer() > > > tightening from Martin Koegler. > > > > It seems that for the past few days, people were having too much fun > > bashing how broken MacOS X is, and the real work has stalled in the > > meantime. Well, not really stalled but they certainly made the patches > > and discussions harder to find in the list archive. > > > > [...] > > > > But there are still unapplied patches that deserve attention. The one > > that I am most worried about is Grégoire Barbier's http-push changes: > > > > $gmane/70406 <1200250979-19604-1-git-send-email-gb@gbarbier.org> > > This patch makes http-push Warn if URL does not end if "/", but it would > be even better to just handle it... we know exactly that HTTP URLs _must_ > end in a slash. > > It gives a better warning if the URL cannot be accessed, alright. But I > hate the fact that it introduces yet another function which does a bunch > of curl_easy_setopt()s only to start an active slot and check for errors. > > Currently, I am not familiar enough with http-push.c to suggest a proper > alternative, but I suspect that the return values of the _existing_ calls > to curl should know precisely why the requests failed, and _this_ should > be reported.
FWIW, I have a work in progress refactoring the http code, avoiding a great amount of curl_easy_setopt()s and simplifying the whole thing. It's been sitting on my hard drive during my (quite long) vacation. I will probably start working again on this soonish.
Mike