Repository navigation
submodule_update() throws error and does not mimick git behaviour #93
Description
Hi!
Say you add a submodule to a repo by doing git submodule update --init, and then do git submodule update --init again to update it, git does not complain and just gives the same output as before.
In gitpython, this gives an error:
repo.submodule_update(init=True)
---------------------------------------------------------------------------
OSError Traceback (most recent call last)
<ipython-input-6-86ea9b78455b> in <module>()
----> 1 repo.submodule_update(init=True)
/usr/lib/python2.7/dist-packages/git/repo/base.pyc in submodule_update(self, *args, **kwargs)
265 take the previous state into consideration. For more information, please
266 see the documentation of RootModule.update"""
--> 267 return RootModule(self).update(*args, **kwargs)
268
269 #}END submodules
/usr/lib/python2.7/dist-packages/git/objects/submodule/root.pyc in update(self, previous_commit, recursive, force_remove, init, to_latest_revision, progress, dry_run)
293 # update the submodule using the default method
294 sm.update(recursive=False, init=init, to_latest_revision=to_latest_revision,
--> 295 progress=progress, dry_run=dry_run)
296
297 # update recursively depth first - question is which inconsitent
/usr/lib/python2.7/dist-packages/git/objects/submodule/base.pyc in update(self, recursive, init, to_latest_revision, progress, dry_run)
376 os.rmdir(module_path)
377 except OSError:
--> 378 raise OSError("Module directory at %r does already exist and is non-empty" % module_path)
379 # END handle OSError
380 # END handle directory removal
OSError: Module directory at '/home/me/gitpython-test/somesubmodule' does already exist and is non-empty
Of course it exists, but imo gitpython should not error out about it (just like git does not). same happens when omitting the init=True option.
git.__version__: '0.3.2 RC1'
repo.git.submodule('update') works, though. although it does not display the output that git does, at least it doesn't seem to fail.
Activity
Byron commentedon Nov 19, 2014
git-pythons submodule implementation will need a proper review, as it has many flaws (by now), not properly implementing gits own submodule handling.
Byron commentedon Jan 19, 2015
The test-suite has been adjusted to test for your case specifically.
Fortunately I was unable to reproduce the issue in the upcoming release, which strengthens my impression that the issue was caused by submodules which used .git files (instead of the actual repository).
Byron commentedon Jan 19, 2015
The archived live-stream can be found on youtube
bilderbuchi commentedon Jan 19, 2015
thanks for fixing the bug! (although I have to admit I haven't used gitpython since the time when I reported the bug)
Byron commentedon Jan 19, 2015
There is a time for everything, after all I didn't look at git-python for several years myself. And look who is back now ;).