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