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
Non-GitPy GitRepo.get_branch_commits() #3834
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3834 +/- ##
==========================================
+ Coverage 89.13% 89.17% +0.04%
==========================================
Files 275 275
Lines 35847 35825 -22
==========================================
- Hits 31953 31948 -5
+ Misses 3894 3877 -17
Continue to review full report at Codecov.
|
LGTM |
The changes themselves look fine to me, but the crawler uses get_branch_commits(). So we either need to (1) prepare an adjustment PR against the crawler or (2) keep get_branch_commits() around for now (or both). The crawler already contains several unreleased compatibility fixes, so I think no. 1 would be fine.
Repo classes have no `get_branch_commits()` anymore. The crawler uses the test-helper replacement now. it could eventually also swallow that function into its code base.
I prepared an adjustment PR for the crawler datalad/datalad-crawler#66 I would merge this when the test have gone through. |
datalad/tests/utils.py
Outdated
@@ -1827,6 +1827,37 @@ def newfunc(*args, **kwargs): | |||
return newfunc | |||
|
|||
|
|||
def get_branch_commits(repo, branch=None, limit=None, stop=None): | |||
"""Return commit hexshas for a branch |
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.
My main question is - why not to keep it as a method (well, rename to get_branch_commits_
) of GitRepo and just remove value
parameter, thus always yielding hexsha
s?
or we do not foresee any need for such functionality for anything but the tests? I already see one usecase RFed above in https://github.com/datalad/datalad/pull/3834/files#diff-18445826672fc8f047d0b7d56512986cR327 for direct call to git
(IMHO suboptimal to breed those)
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 idea here, and in other PRs before, is to get rid all these tiny wrapper around simple git calls and leave them to the return value focused wrappers we have now. I was under the impression that this direction had received general support. I dont see why this particular method should be treated differently.
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.
I have now implemented what you suggested @yarikoptic and adjusted the companion PR in the crawler too.
b66e98f
to
b9930f1
Compare
See datalad/datalad#3834 Compatibility kludges have been put in place, given that the impact on the crawler is just a rename.
GitRepo.get_branch_commits()
as a non-test-helperand add '_' function name suffix to indicate its generator-behavior. This furthers datalad#2970
I have dropped all changes that removed this method from the class and turned into a standalone function.
|
As with other PRs the windows github ci failure is unrelated. Crawler failure is addressed in companion PR. |
See datalad/datalad#3834 Compatibility kludges have been put in place, given that the impact on the crawler is primarily a rename.
This is sitting on top of gh-3833. And aims to be another step towards #2970 by fixing #3813
Sibling PR in the crawler is datalad/datalad-crawler#66