Subject: Re: [PATCH 3/3] cat-file: avoid verifying submodules' OIDs

From: Junio C Hamano <[email-masked]>
Date: Wed, 13 Mar 2024 08:22:16 -0700

Jeff King <[email-masked]> writes:

> I think you could make an argument that the problem is
> shoe-horning new, slightly-mismatched functionality into
> cat-file. But there are lots of practical reasons to want to do
> so, as we discussed elsewhere.  Since gitlinks are the only place
> where we'd expect an object to be missing, "simulating" them here
> isn't too bad.

100% agreed.  This is something we should be asking about "HEAD:"
tree object, not about "HEAD:sha1collisiondetection" object, if we
are to ask cat-file.  After all "cat-file p HEAD:" tells us that the
thing is a submodule already.  But unfortunately the "--batch" thing
is limited to "give me an object and what you want to know about the
object, and I'll tell you what I know about it" exchange, so it is a
very bad match when you cannot really give it an object (which you
do not have, like the target of the gitlink).  So...

> But I suspect there's a more
> general solution where cat-file learns to print dummy values for any
> missing object, letting the caller see what we _could_ find out. And
> then the submodule case just falls out naturally. I doubt we could make
> it the default for historical compatibility; we'd need a new option.

... "--batch" obviously needs to be extended, and %(objectmode) may
be one direction to do so, but it would also work to allow us to ask
about "HEAD:" and what it has at paths, which match a pathspec
"sha1collisiondetection", an equivalent to give "cat-file --batch" a
command to drive "ls-tree".

> This is all speculative on my part, of course. Probably Dscho or
> Victoria can explain their use case better. :)

Likewise.