Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Apr 27, 2015, 18:38 UTC
- Message-ID
- <CAPig+cTcAq_p3QXqcG+o1saWZyvDHCW=_JWYn6s7B1L4X5X1cQ@mail.gmail.com>
- In-Reply-To
- <553E2427.4090700@gmail.com>
On Mon, Apr 27, 2015 at 7:57 AM, karthik nayak <karthik.188@gmail.com> wrote:
Show 26 quoted lines
> On 04/25/2015 10:34 PM, Junio C Hamano wrote: >> karthik nayak <karthik.188@gmail.com> 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.