Jeff King <peff@xxxxxxxx> 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.
