You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The tests are failing since the introduction of the --progress support. The issue being inconsistent failing of the same code between calls. Cf the travis reports.
With a fair bit of debugging, I found out the issue is that because GitPython relies on the kwargs construct to pass around optional arguments, the order of argument will depend on the order of the items within the dict. As when I introduced progress support, opt_arg contains '-v' and '--progress' now, the order depending on both hash('-v') and hash('--progress'). To fix this, making the optional arguments ordered on their value instead on their hash will do the job, but sadly it's not something that can be fixed with a tiny bit of monkey patching…
* Adding gist feature support
* Adding request for merges feature support
* Applied PR #2 and #3 (token and documentation updates)
* Applied fix for issues #7 and #8, thanks to patch applied on upstream
* Improved testing framework (removed dep to unittest, and made it to
work for travis and locally in a smoother way)
* Version pinning for important deps to avoid uncontrolled breakage in
the future
The tests are failing since the introduction of the
--progress
support. The issue being inconsistent failing of the same code between calls. Cf the travis reports.With a fair bit of debugging, I found out the issue is that because GitPython relies on the
kwargs
construct to pass around optional arguments, the order of argument will depend on the order of the items within the dict. As when I introduced progress support,opt_arg
contains'-v'
and'--progress'
now, the order depending on bothhash('-v')
andhash('--progress')
. To fix this, making the optional arguments ordered on their value instead on their hash will do the job, but sadly it's not something that can be fixed with a tiny bit of monkey patching…Thus, I've opened a PR upstream at gitpython-developers/GitPython#431 with a very simple fix for that.
The text was updated successfully, but these errors were encountered: