On Mon, 18 Aug 2025 at 18:50:49 +0100, Ian Jackson wrote:
What actually causes the real failure is not the presence of the
`.gitmodules` files in the toplevel. It's the weird git object
structure, where the tree object references a commit object rather
than a blob or another tree.
In principle I think the git submodule tooling is supposed to maintain
these two things sort of roughly maybe in sync.
Sort of. The contents of a non-empty /.gitmodules are a statement about
what the (upstream) maintainer wants `git submodule update` to do: "if
$path is a submodule, update it to the latest from $url". It doesn't
usually contain a specific commit sha1, only a remote URL and an
optional non-default ref to fetch. Typically it's maintained by letting
`git submodule` subcommands edit it, but it is equally possible to
change it with a text editor.
The submodule itself is the commit-object-as-child, which contains a
specific commit sha1, but no remote URL or ref name. The redundancy
between the two is that /.gitmodules and the tree both contain a list of
(possible or actual) paths-that-are-submodules.
Even a non-empty .gitmodules doesn't *necessarily* indicate a problem,
as seen in src:gnome-control-center. In the upstream project,
subprojects/gvc is a submodule (it's a "copylib" with an unstable API,
intended to be vendored), but in the version packaged in Debian, our
upstream branch is based on upstream's `meson dist` output, which
converts submodules into the full content of its corresponding tree,
leaving the overall tree as the same thing we'd get if upstream had been
using `git subtree` instead of `git submodule`. However, the `meson
dist` tarball does contain the /.gitmodules file (it isn't special-cased
to be removed, unlike the /.git/ directory), therefore so does our
upstream branch. dgit can upload this successfully, because there is
actually no inconsistency between the upstream branch and the orig
tarball when you try it, but git-debpush warns.
Probably we should be checking for anomalous objects in the tree.
I think ideally git-debpush would check for the actual submodule (or more
generally, a tree containing object types that it doesn't/can't support)
rather than .gitmodules, if that is something that can be done
reasonably efficiently at tagging time.
smcv
