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

Run git fetch with --quiet by default #489

Closed
oowekyala opened this issue Apr 30, 2021 · 5 comments
Closed

Run git fetch with --quiet by default #489

oowekyala opened this issue Apr 30, 2021 · 5 comments

Comments

@oowekyala
Copy link

The log output would be cleaner if the clone/fetch command used the --quiet option. This way, the download progress would not be output in logs:

 remote: Counting objects:   0% (1/459)        
 remote: Counting objects:   1% (5/459)        
 remote: Counting objects:   2% (10/459)        
 remote: Counting objects:   3% (14/459)        
 remote: Counting objects:   4% (19/459)        
 remote: Counting objects:   5% (23/459)        
 remote: Counting objects:   6% (28/459)        

Currently this prints one line per 1 or 2 % progress, for each of remote: Counting objects, remote: Compressing objects, Receiving objects, and Resolving deltas. This is as much as 400 lines of useless logs, maybe more for very big repos.

@oowekyala
Copy link
Author

Found #18...

@swharden
Copy link

swharden commented Oct 8, 2021

This is as much as 400 lines of useless logs, maybe more for very big repos

I find this jarring to the viewer (the text scrolls faster than it can be read). It is also a waste of bandwidth. It's not that much bandwidth individually, but at scale the waste must be impressive.

Has a way been implemented/documented for disabling this noisy output?

@Allon-Guralnek
Copy link

@oowekyala I don't think this should be closed because #18 was closed as "resolved" due to them adding log grouping/collapsing to the UI. But the fact is, it doesn't solve the huge amount of logs this needlessly generates. So I think there should be some open issue about this so it's addressed.

@oowekyala
Copy link
Author

@Allon-Guralnek I think you're right, but I think it would be more appropriate for the original ticket to be reopened

@simonbaird
Copy link
Contributor

FYI there's a PR for this at #1067.

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

4 participants