Repository navigation
git.Repo.submodule_update check for remote branch even though "to_latest_revision=False" #545
Description
As I understand the doc, "to_latest_revision" should work similar to --remote as in "git submodule update --remote". However, GitPython still check remote branches even though "to_latest_revision" is set to False.
Basically I want to do this:
$ git submodule update --init --recursive
But since I have a branch in my .gitmodules file that doesn't exist remote then I get the following error:
File "C:/Users/myuser/fetch_submodules.py", line 84, in setup_repo
repo.submodule_update(recursive=True, force_reset=True, force_remove=True)
File "C:\Python27\lib\site-packages\git\repo\base.py", line 305, in submodule_update
return RootModule(self).update(_args, *_kwargs)
File "C:\Python27\lib\site-packages\git\objects\submodule\root.py", line 327, in update
progress=progress, dry_run=dry_run, force=force_reset, keep_going=keep_going)
File "C:\Python27\lib\site-packages\git\objects\submodule\base.py", line 529, in update
remote_branch = find_first_remote_branch(mrepo.remotes, self.branch_name)
File "C:\Python27\lib\site-packages\git\objects\submodule\util.py", line 38, in find_first_remote_branch
raise InvalidGitRepositoryError("Didn't find remote branch '%r' in any of the given remotes" % branch_name)
git.exc.InvalidGitRepositoryError: Didn't find remote branch ''.'' in any of the given remotes
Should GitPython care about my .gitmodules branch when I don't specify "to_latest_revision=True"?
Why I need to have a branch in .gitmodules that doesn't exist remote maybe doesn't make much sense but it has to do with Gerrit Code-Review submodule subscription that automatically updates the super repo for each submodule commit. See https://gerrit-documentation.storage.googleapis.com/Documentation/2.13.2/user-submodules.html#_defining_the_submodule_branch for further details.
.gitmodules
[submodule "common"]
path = common
url = ssh://gitrepourl/repo
branch = .
I hope i don't misunderstand "to_latest_revision".
Activity
Byron commentedon Dec 8, 2016
Assuming that
git submodule update --init --recursiveworks despite the non-existing branch makes me believe that GitPython shouldn't overly rely on it being present either. Interestingly, the code path could also ignore the issue. Looking at the code, it was intended to be able to do that, but maybe a change in exceptions makes it fail now.I will see if the fix is as simple as it seems.
Byron commentedon Dec 8, 2016
Indeed, that makes the fix actually a hack that might make things worse for some. GitPython will now emit a log message, but not behave correctly. Maybe using git directly is advised in this case (e.g.
repo.git.submodule('update', '--init', '--recursive').The reason one would want to use GitPython's submodule implementation is only if one wants to have smart behaviour, that is to automatically remove submodules when they have been removed, with support for changing URLs on the fly to existing submodules.
to_latest_revision=Truedoes not affect the handling of the branch name., which is interpreted literally at all times.Interestingly, during the inception of the submodule support of GitPython, I added the 'branch' feature myself as it was one of my requirements to make submodules useful.
@jlycke Do you think it would be better to let GitPython crash hard in this case (and evert my previous commit)?
fix(submodule): don't fail if tracking branch can't be setup