git.Repo.submodule_update check for remote branch even though "to_latest_revision=False"

[ghost]

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".

[Byron]

Assuming that git submodule update --init --recursive works 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.

[ghost]

Thank you for the fix!

As a note, support for branch = "." in the .gitmodules file has been added in git 2.10.2.

https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.10.2.txt
* Recent git allows submodule.<name>.branch to use a special token
"." instead of the branch name; the documentation has been updated
to describe it.

https://git-scm.com/docs/gitmodules
submodule.<name>.branch
A remote branch name for tracking updates in the upstream submodule. If the option is not specified, it defaults to master. A special value of . is used to indicate that the name of the branch in the submodule should be the same name as the current branch in the current repository. See the --remote documentation in git-submodule[1] for details.

I don't know how GitPython handle the "." if "to_latest_revision" is set to True. I assume that the wanted behavior is now that "git submodule update --remote" with a .gitmodules file with branch = "." should behave the same as git 2.10.2. That is fetch a submodule branch with the same name as the current branch in the current super repo.

[Byron]

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=True does 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)?

[ghost]

@Byron I already use repo.git.submodule('update', '--init', '--recursive') which works for me, no problem reverting the commit. And thanks for creating #556 .