Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option

Eric Sunshine [off-list ref] writes:

It's easy to be blinded into thinking that cat-file's new option
should be named --literally since it was inspired by the --literally
option of hash-object, but indeed it may not be the best choice.

Yeah, I wouldn't even say "inspired".  It was envisioned as a
counter-part debugging aid, nothing more.

Is there any other way to make cat-file looser other than accepting
an unknown type name from the future?  If so, then perhaps it may
make sense to give it a generic name that implys 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.

Thanks.

On 04/22/2015 02:06 AM, Junio C Hamano wrote:

Eric Sunshine [off-list ref] writes:

quoted

It's easy to be blinded into thinking that cat-file's new option
should be named --literally since it was inspired by the --literally
option of hash-object, but indeed it may not be the best choice.

Yeah, I wouldn't even say "inspired".  It was envisioned as a
counter-part debugging aid, nothing more.

Is there any other way to make cat-file looser other than accepting
an unknown type name from the future?  If so, then perhaps it may
make sense to give it a generic name that implys 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.

quoted

     --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. Is the size worth the trade-off for a better description?

Thanks.