Junio C Hamano <gitster@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html