From: karthik nayak Date: Tue, 28 Apr 2015 12:03:27 GMT Subject: Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option Message-ID: <553F770F.9030106@gmail.com> In-Reply-To: On 04/28/2015 12:08 AM, Eric Sunshine wrote: > On Mon, Apr 27, 2015 at 7:57 AM, karthik nayak wrote: > > On 04/25/2015 10:34 PM, Junio C Hamano wrote: > >> karthik nayak 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. > You do have a point, thanks for putting it out. Will stick to "--allow-unkown-type".