From: Karthik Nayak Date: Mon, 20 Apr 2015 08:57:44 GMT Subject: Re: [PATCH v8 2/4] cat-file: teach cat-file a '--literally' option Message-ID: <8CBC4DEB-EC50-4DD7-A687-443AA93A96A8@gmail.com> In-Reply-To: <20150420074433.GA30422@hashpling.org> On April 20, 2015 1:14:34 PM GMT+05:30, Charles Bailey wrote: >> On 20 Apr 2015, at 06:30, Junio C Hamano wrote: >> Charles Bailey writes: >> >>> The option isn't a true opposite of hash-object's --literally >because >>> that also allows the creation of known types with invalid contents >(e.g. >>> corrupt trees) whereas cat-file is quite happy to show the >_contents_ of >>> such corrupt objects even without --literally. >> >> Not really. If you create an object with corrupt type string (e.g. >"BLOB" >> instead of "blob"), cat-file would not be happy. > >Sorry, the emphasis should have been on "complete" of "complete >opposite". There are some types of bad objects that can be created >only >with hash-object --literally (malformed tag or tree), for which >cat-file >works with fine and there are other types (pun unintended - BLOB, Sorry, but I didn't get you, broken objects created using hash-object --literally do not work with cat-file without the --literally option. >wobble, etc.) for which --literally/--unchecked is required with >cat-file. > >So I meant that cat-file's --literally is only a partial "opposite" or >analogue of hash-object's. > >--allow-invalid-types? --force (in the sense of "suppress some possible >errors")? It's not a big thing but I'm aware that if we can find a >better >name then now would be the best moment. If not, then --literally it is. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.