Junio C Hamano <gits...@pobox.com> writes:

> That does not mean the patch will give us a broken behaviour,
> though.  It just means the ifeq/else part will be redundant.
>>      endif
>> +
>> +    ifeq "$(CURL_LIBCURL)" ""
> This will catch the "$(shell $(CURL_CONFIG) --libs) assigned an
> empty string to CURL_LIBCURL" case, so the result is good.
> I haven't checked what it would look like if we turn this into an
> incremental patch to be applied on top of 'master' (which would give
> us a place to document better why we do not rely on the presense of
> curl-config), but if we can do so, that would be more preferable
> than having to revert the merge of the previous one and then
> applying these two patches anew.

And I just checked; it is not very pretty to call it "trivially
correct", and I would feel safer to revert the merge for 2.0, and
queue the new one for the next cycle, cooking it in 'pu' and then
'next' in the meantime.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to