Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > Glen Choo <chooglen@xxxxxxxxxx> writes: >> > What's the error message printed to the user here? (Just from reading >> > the code, I would have expected this to succeed, with the submodule >> > fetch being from same-name-1's submodule since we're fetching submodules >> > by name, but apparently that is not the case.) >> >> Yeah, I think this might trip up some readers. The message is: >> >> From ../same-name-2 >> b7ebb59..944b5ac master -> same-name-2/master >> Fetching submodule submodule >> fatal: git upload-pack: not our ref 7ff6874077503acb9d0a52e280aaed9748276319 >> fatal: remote error: upload-pack: not our ref 7ff6874077503acb9d0a52e280aaed9748276319 >> Errors during submodule fetch: >> submodule >> >> Which, I believe, comes from how we fetch commits by oid: >> >> static int get_next_submodule(struct child_process *cp, struct strbuf *err, >> void *data, void **task_cb) >> [...] >> oid_array_for_each_unique(task->commits, >> append_oid_to_argv, &cp->args); >> >> When the following is true: >> >> - the submodule is found in the index >> - we are fetching submodules unconditionally (--recurse-submodules=yes") >> - no superproject commit "changes" the submodule >> >> task->commits is empty, and we just fetch the from the submodule's >> remote by name. But as long as any superproject commit "changes" the >> submodule, we try to fetch by oid, which, as this test demonstrates, may >> fail. > > Ah, so we try to fetch an OID from a submodule given by a fetched > commit, which is different from the submodule the client already has > locally. This might be a sign that we need to store more information > about the submodule so that we can print a clearer message. I haven't > looked into this deeply, but this might be possible by putting more > information in the util of changed_submodule_names, and when we have > already seen that submodule, to add more information to the util instead > of skipping it. Storing the submodule URL might achieve this purpose, but if the URL doesn't match, I think we'd want to skip the commit instead of trying to fetch a commit from an unrelated URL. I don't know if this is a good idea though yet - I haven't looked deeply into what Git uses the URL for and whether users might want to change the URL even though the submodule is the 'same' (e.g. pointing the URL to another remote instead of having two completely different repos with the same submodule name).
