On Mon, Apr 27, 2015 at 7:57 AM, karthik nayak <karthik.188@xxxxxxxxx> wrote: > On 04/25/2015 10:34 PM, Junio C Hamano wrote: >> karthik nayak <karthik.188@xxxxxxxxx> writes: >> > Yes this gives the best description, but its large, while we could use >> > something like --no-strict instead. >> >> We could, if you answered my first question with "no". >> >> By naming this "--no-strict", the first bug report you will receive >> may be that "cat-file --no-strict" should parse a zlib deflate that >> begins with "blob 1234\n\0" (notice that there are two SPs instead >> of the usual one, and length is followed by LF that should not be >> there before the NUL) but it does not. >> >> As your option name "--no-strict" signals that you will make the >> best effort to parse such nonsense, that would be a valid bug >> report, against which you would need to update the code to make it >> work. But is it worth the effort to make such a thing work? I >> dunno. >> > Nice point, I don't see the need to parse such objects at the moment. > That rules out "--no-strict" and everything similar. > > I still find "--allow-unkown-type" a bit too big, what about something like > > * --any-type > * --arbitrary-type As a diagnostic aid when encountering a (hopefully rare) broken or corrupt object, this option is not likely to be used often. The "allow" in --allow-unknown-type conveys the intended purpose more accurately than either of the shorter names suggested above; and considering how infrequently it is likely to be used, the extra six characters should not be a significant burden. -- 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