Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option
- From
karthik nayak <karthik.188@gmail.com>
- Date
- Apr 27, 2015, 11:57 UTC
- Message-ID
- <553E2427.4090700@gmail.com>
- In-Reply-To
- <xmqqsiboyw90.fsf@gitster.dls.corp.google.com>
On 04/25/2015 10:34 PM, Junio C Hamano wrote:
Show 30 quoted lines
> karthik nayak <karthik.188@gmail.com> writes: > > >> Is there any other way to make cat-file looser other than accepting > >> an unknown type name from the future? If not, then perhaps it may > >> make sense to give it a generic name that implies that we would > >> trigger such additional looseness in the future. But as the > >> inventor of it as a debugging aid, I would say a name that spells > >> out the specific way this option is being loose, e.g. > >> > >>> --allow-bogus-type > >> > >> or with s/bogus/unknown/, best describes what it currently does. > > > > 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