-
Notifications
You must be signed in to change notification settings - Fork 110
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
More correct summary reporting for relaxed (no size) --annex #7050
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## maint #7050 +/- ##
========================================
Coverage ? 75.83%
========================================
Files ? 354
Lines ? 58934
Branches ? 6616
========================================
Hits ? 44693
Misses ? 14227
Partials ? 14
☔ View full report in Codecov by Sentry. |
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.
In principle seems reasonable to me.
Would prefer to not get the size in the renderer, but it's not instantly clear to me where it should go. Unconditionally in get_content_info seems wrong,too, since this could be quite expensive even when this information isn't needed at all.
there were no objections. Indeed renderer might be a suboptimal spot but we agreed on no better one. Adding changelog as promised. |
Inspired by a fix we needed for push: datalad#7049 I looked into status to realize that we do not even consider those files for which git-annex would not report bytesize. This commit makes them considered in count but would assume 0 bytesize for "recorded" etc. It would not address the issue that we would still not consider/interrogate sizes for those files even if their content available: $> datalad status --annex=all 2 annex'd files (0.0 B/0.0 B present/total size) $> ls -lL * -r-------- 1 yoh yoh 0 Sep 20 15:52 123.dat -r-------- 1 yoh yoh 723 Sep 20 15:57 sample3.csv where sample3.csv is the relaxed one.
…content Follow up to previous fix, where we could not provide stats on size for relaxed files. I guess similar check could be moved deeper in the code and assign bytesize there, for now did right at the rendering stage
appveyor on mac - unrelated
lets' proceed since no objections voiced -- if any comes, submit a PR to remove/redo |
PR released in |
See individual commits for more info. Inspired by #7049
also thought to tune up
bytes2human
to not report odd looking float Byte sizes such as1.0 B
instead of1 B
but decided to not bother .