Re: [PATCH 3/3] cat-file.c: add batch handling for submodules

From: Victoria Dye <vdye@github.com>
Date: Jun 5, 2025, 00:12 UTC
Message-ID: <2eb54073-20b3-465a-ad11-a2f22eb55930@github.com>
In-Reply-To: <20250604195455.GB1500045@coredump.intra.peff.net>

Jeff King wrote:

Show 12 quoted lines

> On Mon, Jun 02, 2025 at 06:55:55PM +0000, Victoria Dye via GitGitGadget wrote:
> 
>> To disambiguate without needing to invoke a separate Git process (e.g.
>> 'ls-tree'), print the message "<oid> submodule" for such objects instead of
>> "<object> missing". In addition to the change from "missing" to "submodule",
>> the new message differs from the old in that it always prints the resolved
>> tree entry's OID, rather than the input object specification.
> 
> OK. I read over the discussion from last year, which I think mostly
> centered around this patch. I do still think in the long run it would be
> nice for cat-file to produce what output it _can_ for a missing object
> (e.g., the oid and mode).

One way to handle that could be changing the message to something like:

submodule SP <mode> SP <oid>

but...

Show 13 quoted lines

> 
> But I think it is OK to punt on that for now. Because "<oid> missing"
> lines already exist, we'd probably need to put such behavior behind a
> new command-line option. So while "<oid> submodule" lines would be
> unnecessary in that hypothetical future world, we are not digging the
> hole any deeper, from a backwards-compatibility standpoint.
> 
> Although speaking of backwards compatibility, I guess older readers may
> be surprised that the old "missing" message becomes a "submodule" one.
> They may need to be updated if they were written carefully to bail on
> unknown input (and were happy seeing "missing" messages for submodules).
> So there may be some fallout, but it's not like the existing messages
> were particularly useful in the first place.

...I suspect that'd be even less compatible with existing automation around 'cat-file' than just swapping out "submodule" for "missing", and users can theoretically infer that the mode is 160000 (S_IFGITLINK). That said, if at some point in the future we support submodules with a different mode, then an explicit value would be fairly useful.

Happy to change it or keep it the same, I have no strong preference either way.

Show 12 quoted lines

> 
>> Note that this implementation maintains a distinction between submodules
>> where the commit OID is not present in the repo, and submodules where the
>> commit OID *is* present; the former will now print "<object> submodule", but
>> the latter will still print the full object content.
> 
> Hmm, that is an interesting point. It feels kind of arbitrary, but I'm
> having trouble making a strong argument for one direction or the other.
> The way you've written it means that readers need to be prepared to
> parse _both_ the mode and "<oid> submodule" lines to find submodules.
> But maybe there's some value in finding out more information about
> submodule commits you do have in-repo.

This was pretty much my thought process on it. It was a somewhat arbitrary choice, but what tipped me towards distinguishing the cases is that I'd rather have information like size, content, etc. about a commit and not need to use it, than need it but not have it available. That, and it does maintain the existing treatment of self-referential submodules.