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

From: Jeff King <peff@peff.net>
Date: Mar 12, 2024, 08:58 UTC
Message-ID: <20240312085854.GA94437@coredump.intra.peff.net>
In-Reply-To: <951f73397c15f76da75bbd74a02f36da0116623f.1710183362.git.gitgitgadget@gmail.com>

On Mon, Mar 11, 2024 at 06:56:02PM +0000, Johannes Schindelin via GitGitGadget wrote:

Show 12 quoted lines

> diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
> index de29e6d79d9..69b50d2042f 100644
> --- a/Documentation/git-cat-file.txt
> +++ b/Documentation/git-cat-file.txt
> @@ -412,6 +412,11 @@ Note also that multiple copies of an object may be present in the object
>  database; in this case, it is undefined which copy's size or delta base
>  will be reported.
>  
> +Submodules are handled specially in `git cat-file`, as the objects
> +corresponding to the recorded OIDs are not expected to be present in the
> +current repository. For that reason, submodules are reported as having
> +type `submodule` and mode 1600000 and all other fields are zeroed out.

I think there's an extra 0 in the mode here?

It may also be worth being more explicit about when Git knows something is a submodule. Naively, reading the above I might think that:

  git ls-tree --format='%(objectname)' HEAD | git cat-file --batch-check

would do something special with submodules. But it can't, as there's no context carried in just the objectname. This is obvious if you are familiar with how Git works, but I'm not sure it would be for all end users. So we could say something along the lines of:

  When `cat-file` is given a name within a tree that points to a
  submodule (e.g., `HEAD:my-submodule`), ...

-Peff