On Thu, Feb 27, 2025 at 07:16:28PM -0500, Taylor Blau wrote: > On Tue, Feb 25, 2025 at 05:47:56PM -0800, Junio C Hamano wrote: > > Jeff King <peff@xxxxxxxx> writes: > > > > > It really makes me wonder if this "unknown type" stuff has any value > > > at all. You can create an object with any type using "hash-object > > > --literally -t". And you can ask about its type and size. But you can > > > never retrieve the object content! Nor can you pack it or transfer it, > > > since packs use a numeric type field. > > > > Correct. IIRC, the "--literally" support was mostly for debugging, > > and as you noticed, is very much limited because it can only create > > funny objects that are loose. And the debugging was not really about > > adding more object types, but was more about "what would our code do > > when we see an object that is corrupt whose type we do not recognise". > > > > I personally think the "--literally" should not survive the Git 3.0 > > boundary. > > It is quite useful for testing intentionally broken objects, like > commits with malformed author/committer lines, or trees with > out-of-order entries, etc. > > Perhaps we could replace that with a test helper that is only accessible > within the test suite that acts like "hash-object --literally" and > remove "--literally" from the plumbing interface? I dunno. I don't want to get rid of --literally. It is great not only for testing and debugging, but also if you needed to recreate a slightly broken object (e.g., to recover from corruption). Hash-object will complain about objects that fail fsck, even though they are perfectly usable (and may be embedded in existing history). But this unknown type stuff is not and has never been usable. So I'd propose to keep --literally but always reject unknown types. -Peff
