Skip to content

Implement update call when the object is "up to date" #871 #872

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

Closed

Conversation

t89
Copy link
Contributor

@t89 t89 commented May 7, 2019

In the current state the update() method of RemoteProgress is not called, if the progress terminates with ** = [up to date]**.

With this implementation, the method gets called once, containing all useful pieces of information. By passing current_count = 1 and max_count = 1 we assure that any percentage calculation terminates with 100%.

TODO:

  • Please check, if the op_code = 0 makes sense in this case
  • I opted for a more future proof, yet slower solution in the elif:
    • to trade durability for performance, use .startswith(' = [up to date]')

Copy link
Contributor

@jeking3 jeking3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need some sort of test that exercises this and proves the update occurs?

@t89
Copy link
Contributor Author

t89 commented May 8, 2019

Sure. When I cloned your repository I used tox to make an initial testrun and the tests failed right out of the box. I looked at the closed (implemented) pull requests and saw that most of them fail the tests, so I didn't bother to investitage the test cases any further.

I'm relatively new to Python unit tests. Can you point me in the right direction? I do appreciate it.

@jeking3
Copy link
Contributor

jeking3 commented May 8, 2019

I am able to do a clean "git clone" followed by "tox" and it tests py27, py36, py37 locally and successfully.

@t89
Copy link
Contributor Author

t89 commented May 10, 2019

test.log
I ran $ git pull main master, installed the (test-)requirements.txt using pip install -r and ran tox / nosetests both terminate with the same result:

FAILED (SKIP=41, errors=10, failures=3)

I can reproduce this two machines. Suggestions?

Running $ nosetests yields the same result.

@t89
Copy link
Contributor Author

t89 commented May 10, 2019

I also investigated your testfile regarding the updated method and I know too little about GitPython's internals to write the test. Like I mentioned in my initial pull-request, I kindly ask the maintainer of the repo to insert the correct op_code, etc. pp.

@t89
Copy link
Contributor Author

t89 commented May 13, 2019

Any feedback on this topic? "It works on my machine" isn't really helpful at all. A part of my current project relies on this functionality and I would like to put in the time to make this pull-request easily mergeable for you.

To write a proper test for this pull-request it would be great to know...

  • ...a hint on where to start to fix the unit-tests of GitPython (see log in earlier post)
  • ...which op_code you would like me to send to the update() method when the project status is = [up to date]
  • ...how you would implement a test inside your project which tests, if update() is called when _parse_progress_line() is passed Git's up-to-date-status.
    • Should I create a local flag inside the test class to know when update should have been called? This seems messy and maybe there is a pythonic way of handling this more elegantly.

Thanks for your time.

@jeking3
Copy link
Contributor

jeking3 commented May 13, 2019

It may be that you have a very old or very new version of git? What does git --version say?

@Byron
Copy link
Member

Byron commented May 13, 2019 via email

@jeking3
Copy link
Contributor

jeking3 commented May 13, 2019

You may also be running into a bug in the unit test framework - I don't think it can handle anything other than the master branch without errors. I haven't reported it yet (I actually forgot I ran into it months ago), but if you tried to run tox on a branch other than master, that might be why. Perhaps the previous comment has guidance to work around that?

@t89
Copy link
Contributor Author

t89 commented May 22, 2019

Wanted to let you know that I still intend to fix this issue, at the moment I don't have the sparetime thoug. Current workaround is freezing the GitPython dependency oin the current version and overriding the method with my own.

I'll let you know, once I come back to this.

@Byron
Copy link
Member

Byron commented Jan 6, 2021

As part of spring cleaning, I am closing this PR as it was opened more than half a year ago while still being open due to unresolved or remarks.

If this is a mistake or any other action should rather be taken, please let me know in the comments or create a new PR.
Thanks for your understanding and the work that undoubtedly went into this.

@Byron Byron closed this Jan 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants