Skip to content
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

Progress reporting is unclear / unpredictable #2909

Closed
mrackwitz opened this issue Mar 9, 2018 · 1 comment
Closed

Progress reporting is unclear / unpredictable #2909

mrackwitz opened this issue Mar 9, 2018 · 1 comment

Comments

@mrackwitz
Copy link

I see the following right now and was wondering what the percentage and the numbers are about:

git lfs push --all origin
Uploading LFS objects:   7% (13/196), 1.2 GB | 1.3 MB/s

Waiting impatiently for this to complete, I expected the percentage to refer to how much bytes are uploaded, as that would probably give the best prediction about how long it will take. I did actually start to fear that something really went wrong with my migration and that those 7% would account for 1.2GB and there would be 15GB more to upload. 😱 This made me look into the source code what these numbers are actually about.

I think this could be improved by specifying at least that these are files:

Uploading LFS objects:   7% (13/196 files), 1.2 GB | 1.3 MB/s

Even better would be if I could see somehow how much space LFS objects take.

Uploading LFS objects:   7% (13/196 files), 1.2 / 2.4 GB | 1.3 MB/s

In general it would be nice to get some statistics around that out of Git LFS via the CLI.

@ttaylorr
Copy link
Contributor

Hi @mrackwitz, thanks for opening this issue! I think that you raise some great points about the design of the progress meter. Here are some thoughts in response:

I agree that it can be confusing to immediately discern the meaning of (x/y) proceeding the transfer speed amount and speed indicators. The last suggestion that you offered includes all of the same information as the previous design (seen in v2.3.4 and earlier).

Regarding this, I felt that one of the motivating factors for the new design was that the old design was providing too much information and that it was not discernible at-a-glance which numbers meant what.

Regarding your second suggestion, I think that adding "files" makes the progress bar look unlike Git's, and parity with Git's design is a motivating factor for this change. I feel that "files" is implied, since this is the meaningful unit of transfer, so adding it would be unnecessary.

On the whole, I am inclined to leave the new design as-is, for the sake of (1) brevity and (2) consistency. Machine-readable information is available with use of the GIT_LFS_PROGRESS environment variable. That said, if many people disagree with me, I am happy to consider alternate options.

As per the above, I am going to close this issue for now, but please do not hesitate to comment if you agree/disagree with this reasoning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants