On 04/28/2015 12:08 AM, Eric Sunshine wrote:

On Mon, Apr 27, 2015 at 7:57 AM, karthik nayak [off-list ref] wrote:

quoted

On 04/25/2015 10:34 PM, Junio C Hamano wrote:

quoted

karthik nayak [off-list ref] writes:

quoted

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".