-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make the output from Dulwich command class behave like Git #6
Conversation
…t from the Git command class.
Given that we are unlikely to bring back support for Mercurial ever, we can probably drop the Mercurial related classes and tests to make this pass CI. |
Sounds good to me. |
Since we don't really worry about Mercurial I'll try a quick fix first. |
src/pmr2/wfctrl/cmd.py
Outdated
return_code = 0 | ||
if output[1]: | ||
return_code = 1 | ||
return '\n'.join(output[0]).encode(), output[1], return_code |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Popen
return code is captured in the third element (idx 2) of the tuple as per https://github.com/PMR2/pmr2.wfctrl/blob/master/src/pmr2/wfctrl/core.py#L304-L305 - just use that instead? Avoids the condition check and thus the coverage issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Actually went to the core of the problem after I realized these workarounds don't make sense - the problem being the test set up helpers weren't updated to return the 3-tuple. This was fixed so the nonsense handling no need to happen. I pushed to my own fork and will be merging this in shortly after CI is done for that. |
No description provided.