submodule update doesn't work with relative submodule paths (in GitPython 2.1.14)

[Genovese-martijn]

When using the git.objects.submodules.base.Submodule.update method (https://gitpython.readthedocs.io/en/stable/reference.html#git.objects.submodule.base.Submodule.update), the git python module seems to fake a git submodule call with git clone. It executes git clone -n --separate-git-dir=<workspace>/.git/modules/<submodule_path> -v <submodule_url> <workspace>/<submodule_path>. This command doesn't work when a submodule is specified as a relative path in the .gitmodules path. For example:

[submodule "main_project/submodule"]
  path = main_project/submodule
  url = ../../other_project/some_module.git

The git.objects.submodules.base.Submodule.update then fails with `repository '../../other_project/some_module.git' does not exist.

The regular git submodule command is able to resolve the paths.

[Byron]

Thanks for posting. Which version of GitPython are you using?

Even though the submodule implementation may not be up to date with what git produces, I remember that some improvements were made in the past which might resolve this issue.

[Genovese-martijn]

Thanks for the feedback, I am using version 2.1.14 due to external python2 requirement. The issue is indeed resolved when using version 3.0.3.

[Byron]

Thanks for your reply! I am closing this issue as it is already resolved.

Interestingly, in the last released version of GitPython with Python 2 compatibility, the submodule improvements should already be present. If you can spot the difference, I would be happy to receive a PR against 2.1.14 that fixes the issue there as well and release 2.1.15.

[Genovese-martijn]

Sorry, I made a mistake in my setup while I was testing it with python3 and git python version 3.0.3. On version 3.0.3 the relative submodule paths also does not work

[Ferenc-]

This bug is still present in 3.0.5 any chance to increase priority?

[Byron]

I am afraid there is no priority beyond what people decide to contribute. GitPython is in maintenance mode.

[Genovese-martijn]

When looking trough other issues, I think this issue is the same as issue 730. Is there any reason why gitpython doesn't use the "native" git submodule calls?

[Byron]

If memory serves, back in the days I wanted to have 'smart' submodules, that are easier to handle and to update. For that, a lot of additional logic was added to what constitutes a very own implementation, compatible to git-submodules. In retrospect that turned out to be coming with maintenance costs that are now unaffordable.

Luckily, users can always workaround themselves by using repo.git.submodule(…), which may be enough for most usecases.

[BlackFIlms]

I have same trouble. I written the 'relatives' class, and this class can supply full URL, from origin + relative path to submodule. But how i can replace path to submodule in Repo object directly?

[Byron]

But how i can replace path to submodule in Repo object directly?

Due to its nature, it is probably read-only. More details could be provided if there is more information on what's you are trying to do and how it's done.

[atomar94]

My Workaround

I was able to update my relative submodules with:

repo.git.execute(command=['git', 'submodule', 'update', '--init', '--recursive'])

Docs: https://gitpython.readthedocs.io/en/stable/reference.html#git.cmd.Git.execute

GitPython 3.1.26, Python 3.8.10

[Byron]

Thanks for sharing. This can probably be rewritten to repo.git.submodule('update', init=True, recursive=True), giving it a bit of an edge over calling popen entirely by hand.

[yvatyan]

I wasn't able to make it work neither with repo.submodule_update(init=True, recursive=True) nor repo.git.submodule('update', init=True, recursive=True) The latter is due to derivation to wrong git command cmdline: git submodule --init --recursive update

https://github.com/gitpython-developers/GitPython/issues/944#issuecomment-1043410572 solution worked for me.

Git: 2.25.1 GitPython: 3.1.27 Python: 3.8.10

[Byron]

Thanks for letting us know.

I think the takeaway here is that one should avoid GitPython submodules in favor of using reop.git.submodule(…), which uses the git program as one would on the command-line.