Conversation
|
Thanks for your contribution! At this time I unfortunately also don’t know if there are better ways to fix this, but believe it’s OK to assume it’s not making anything worse if the tests are not breaking. |
After trying a few things locally, this seemed to allow the submodule to behave normally. Though would think the name should be coming from
Sorry. Should have included a test. TBH wasn't sure if this seemingly hacky fix would be accepted or so quickly. 😄 Thanks for that. I'll give the test some thought. |
Uses a workaround already accepted upstream to fix `create_submodule` when the submodule already exists. In particular naming the submodule with the user provided name. By being able to use `create_submodule`, this script runs substantially faster than when calling `submodule`. Reason being calling `submodule` lists all submodules in the repo and then selects the one we named. Whereas `create_submodule` simply provides us the requested submodule. So using this workaround is necessary for the performance improvement it provides. ref: gitpython-developers/GitPython#679
…_submodule Store submodule name
2 participants
Fixes #678
Seems there are a plethora of things that expect to be able to get a submodule's name. However it is not defined if
Submodule.addfinds the submodule already exists. This is one attempt at trying to solve this issue.