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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 13, 2024, 15:22 UTC
Message-ID: <xmqqmsr2f97b.fsf@gitster.g>
In-Reply-To: <20240312221758.GA109417@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

> 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...

Show 5 quoted lines

> 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.