On Feb 7 2015 at 9:14 PM Junio C Hamano wrote: >On Sat, Feb 7, 2015 at 2:31 PM, Joachim Schmitz <j...@schmitz-digital.de> >wrote: >> Junio C Hamano <gitster <at> pobox.com> writes: >>> >>> Yup, I agree that is a sensible way to go. >>> >>> (1) if Makefile overrides the size, use it; otherwise >>> (2) if SSIZE_MAX is defined, and it is smaller than our internal >>> default, use it; otherwise >>> (3) use our internal default. >>> >>> And leave our internal default to 8MB. >>> >>> That way, nobody needs to do anything differently from his current >>> build >> set-up, >>> and I suspect that it would make step (1) optional. >> >> something like this: >> >> /* allow overwriting from e.g. Makefile */ #if !defined(MAX_IO_SIZE) # >> define MAX_IO_SIZE (8*1024*1024) #endif >> /* for plattforms that have SSIZE and have it smaller */ #if >> defined(SSIZE_MAX && (SSIZE_MAX < MAX_IO_SIZE) # undef MAX_IO_SIZE /* >> avoid warning */ # define MAX_IO_SIZE SSIZE_MAX #endif >No, not like that. If you do (1), that is only so that the Makefile can >override a broken definition a platform may give to SSIZE_MAX. So > (1) if Makefile gives one, use it without second-guessing with SSIZE_MAX. > (2) if SSIZE_MAX is defined, and if it is smaller than our internal default, > use it. > (3) all other cases, us our internal default.
That is reasonable. I am more concerned about our git-upload-pak (separate thread) anyway :) Cheers, Randall -- 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
