Erik Elfström <erik.elfstrom@xxxxxxxxx> writes: > On Sat, Apr 25, 2015 at 6:47 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> I do not think it is wrong per-se, but the changes in this patch >> shows why hardcoded values assigned to error_code without #define is >> not a good idea, as these values are now exposed to the callers of >> the new function. After we gain a new caller that does care about >> the exact error code (e.g. to react differently to the reason why we >> failed to read by giving different error messages) if we decide to >> revert this step, or if we decide to add a new error type, for >> whatever reason, this organization forces the caller to be updated. > > Yes, it was a bit silly of me not to add that. Would something like > this be ok? Yeah, if you used symbolic constants from the get-go, then the second patch to add the "too-large? it cannot be gitfile" safety would not have to renumber everything; instead it would be adding a single constant to the header file and adding a new case to setup.c that uses the error code. -- 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