Correctly stash with submodules#27
Conversation
Submodule changes cannot be stashed and thus should not be considered when stashing changes. Requires gitpython-developers/GitPython#294 to be applied first.
The old version would consider an empty string as "1 change" where it should be 0. This change is able to determine a 0 count.
|
Thanks for the PR! I'll merge it as soon as the change in GitPython gets approved. |
|
In case you haven't seen, the PR has been merged, though I don't know whether you want to wait until it has also been released as well. |
|
Yeah, it's propably best to wait for a new release of GitPython. Unfortunately its mailing list doesn't seem very active so I'll try to monitor its GitHub project for the new release. |
The pull request gitpython-developers/GitPython#294 has been merged but the API was changed slighty. This commit reflects this change so that it works again.
|
I have updated the changes so that the changed API resulting from merging the PR are reflected here as well. Without this, this PR would break |
msiemens
force-pushed
the
master
branch
7 times, most recently
from
c6a99f0 to
4107474
Compare
|
It's been a while, but a new version of GitPython that includes your patch has finally been released. So your PR is now merged, I'll try to set up some test cases and then we can release an update of PyGitUp, too. |
2 participants
I had a problem where a submodule has uncommitted changes. git up would choke on this, because
is_dirtyreportsTruebut there isn't actually a change (the change count is 0, when correctly calculated, see below). Thus stashing would store an empty stash. Then on unstashing it fails because there is no stash. I provided gitpython-developers/GitPython#294 to GitPython to introduce a new argument that allows to ignore submodules when asking foris_dirty. This PR uses that change then.Finally, I noticed the calculation of changes is off: If no change is made, the count would still be 1. Now it's correctly 0 (not something that would actually appear in reality, I guess).
Note that the PR on GitPython needs to be merged first. Beyond that, the version might need a bump in setup.py, but I guess you know that ;-)