Why would 'git submodule update' skip a submodule?

Question

I have a git repo with a single submodule sub/x. (This submodule does not contain any submodules of its own.)

In the superproject's repo, the output of git status shows the following (unstaged) modification

modified:   sub/x (new commits)

If I now run

git submodule update

...on the superproject, the following line gets printed to the terminal (and nothing more):

Skipping submodule 'sub/x'

After this, the output of git status on the superproject remains as shown above, unchanged.

(Ditto if I add --init to the git submodule update command.)

Q: How can I determine why git submodule update [--init] skips the sub/x submodule?

Sori

Answer 1

(Note: I've only checked a very recent Git version, and the submodule code has been undergoing changes, so this might not be the only case. But it is the only place that message can occur in the latest Git.)

Edit 2: it seems that the case below applies when the superproject's .git/config has an explicit update = none setting in it. That makes more sense than the guess I made below; it's the first half of the || expression here. I assumed there was no update = none setting though, and we were getting this from the second half (unspecified and type=NONE) and I still find that confusing.

(original answer continues below)

---

This message appears in the Git submodule helper code:

        if (suc->update.type == SM_UPDATE_NONE
            || (suc->update.type == SM_UPDATE_UNSPECIFIED
                && update_type == SM_UPDATE_NONE)) {
                strbuf_addf(out, _("Skipping submodule '%s'"), displaypath);
                strbuf_addch(out, '\n');
                goto cleanup;
        }

This code fires when there's no submodule.name.update setting set in the superproject's .git/config for the given submodule, and the update type is unspecified (git submodule update without --checkout). So:

git submodule update --checkout

would override this, as would configuring the submodule's update setting to checkout. Edit: I don't understand why the code is this way: the documentation says that the default is checkout, and behaving differently with the actual setting set to checkout, vs defaulting to checkout, does not seem to match this claim.

Stannwood

There's an actual none update type it's looking for – Icj

This is an interesting idea; I can't wait to try it. Unfortunately, I'll have to wait until tomorrow, because the system I'm doing this on just went down for maintenance... – Sori

@jthill: there is, but this seems to apply only to the default (SM_UPDATE_UNSPECIFIED; I did a quick search). There's also this odd notion of active vs inactive submodules, but that seems not to relate to the "skipping" message. I don't understand the intent behind this code, as the documentation says that unset means checkout. – Stannwood

@jthill: sure enough, the superproject's .git/config file had the setting update = none for the sub/x submodule. I have no idea why this setting is there. I know for a fact that I did not add it by manually editing this .git/config file. Some other git command must have adding this setting as a side-effect. – Sori

The situation that gave rise to this post has the hallmarks of my "bull in the China shop" phase: (1) a Git repo that is in a bizarrely borked state, needing hours and hours of troubleshooting, and (2) me not having the faintest idea of how the repo got to such a state. I entered such a phase when I started using Git-with-submodules, but I went through a very similar phase (which lasted for weeks) several years ago, when I first started using (plain, i.e. no-submodules) Git. ... – Sori

...I didn't get past it until I (1) understood Git's fundamental underlying structure and how it is implemented, in very concrete terms; (2) understood how the various Git commands modify this underlying structure; and (3) learned the commands needed to interrogate this structure, for troubleshooting. I need the same thing for Git-with-submodules, but I don't know how to get it. It's going to be some rough weeks ahead. – Sori

Answer 2

Check if your submodule itself is ignored:

git check-ignore -v -- sub/x

Check also the .gitmodules file, for any ignore directive.

Opinicus

Thanks, but both of these came up empty. My version of git does not have check-ignored, but it does have check-ignore. When I ran the command line you posted with check-ignore instead of check-ignored, I got no output. The .gitmodules file has only the path, url, and branch directives for this one module (and nothing else). – Sori

@Sori What version of Git do you have? On which OS? – Opinicus

@Sori Is there a sub/x/.git subfolder which would make x a nested repository, in addition of its submodule status? – Opinicus

the Git version is 2.17.0; the OS is Linux (CentOS); there is a sub/x/.git file, not a subfolder. – Sori

Ok. First test to check, see if the issue persists with git 2.28 – Opinicus