bug#56398: (guix git) fails to check out repos with nested submodules

[André Batista]

qui 04 ago 2022 às 13:59:20 (1659632360), ludovic.courtes@inria.fr enviou:
> But you got a wrong hash I presume, because submodule weren’t actually
> checked out, right?

The submodule was not checked out, sure, but is it the wrong hash
considering it's also not present on the remote repo?

> The problem is that it papers over an actual libgit2 bug.

Does it though? I'm trying to wrap my head over this, but I'm somewhat
unsure that this isn't the intended - expected? - behaviour on this
case:

I've cloned gloo and issued 'git submodule status' and it returns
nothing. I've also issued 'git submodule update --init --recursive'
and it also does nothing. 

The documentation for git-submodule init[1] says "Initialize the
submodules recorded in the index (which were _added and commited_
elsewhere)..." and it also says on 'add' subcommand "Add the given
repo as a submodule at the given path to the changeset to be commited
next to the current project..."

The documentation for gitsubmodules[2] says that submodules can take
the following forms:

- a .git directory, a working directory, a gitlink and a .gitmodules;
or
- a working directory with an embedded .git directory (...)

The description for libgit2's git_submodule_init (which would've been
called if the error was GIT_ENOTFOUND and we were initializing it)
only says "Copy submodule info into .git/config", which coincides with
what 'git submodule init' does. There is also a git_submodule_add_setup
routine which can be called to emulate what 'git submodule add'
would've done.

Finally, libgit2 provides a git_submodule_repo_init routine which would
"set up the subrepository for a submodule in preparation for clone",
instead of just copying the submodule info into .git/config as
git_submodule_init does.

So, I'm inclined to think that this is not a bug on libgit2, but a
result of gloo having misconfigured its submodule and it's not
surprising that 'git_submodule_update' is erroring out. If so, any
program using this library should decide what to do with the returned
error, right?

> I think we should instead report it upstream.  Do you feel like doing
> it?  I guess we’d need to give them the C version of the three-line
> snippet I gave earlier.
> 
> WDYT?

"Feel like doing it" is a stretch, but I'll gladly do it so that at
least we will know that they've considered this scenario and, if they
agree with you, we and other users may have a proper fix. Let's see if
I can conjure some C incantation.

Cheers!

[1] https://git-scm.com/docs/git-submodule
[2] https://git-scm.com/docs/gitsubmodules