{"thread":{"id":"30460","subject":"[PATCH] clone: fix progress-regression","startedAt":"2012-05-07T19:23:13Z","lastAt":"2012-05-08T05:46:50Z","messageCount":3,"participants":["Erik Faye-Lund","Junio C Hamano","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"191027","messageId":"1336418593-2792-1-git-send-email-kusmabite@gmail.com","threadId":"30460","inReplyTo":null,"subject":"[PATCH] clone: fix progress-regression","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-05-07T19:23:13Z","receivedAt":"2012-05-07T19:23:13Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"In 5bd631b3 (\"clone: support multiple levels of verbosity\"), the\ndefault behavior to show progress of the implicit checkout in\nthe clone-command regressed so that progress was only shown if\nthe verbose-option was specified.\n\nFix this by making option_verbosity == 0 output progress as well.\n\nSigned-off-by: Erik Faye-Lund <kusmabite@gmail.com>\n---\n\nHmpf. While tidying this up for a proper submission, I found out that\nwriting a reliable test is tricky due to the start_progress_delay-usage.\nI'd have to clone a repo that does not progress more than 50% of the\ncheckout-operation within one second or something like that (I didn't\nquite follow the logic there), which is a lot :P. This strikes me as\nerror-prone, and I can't see an obvious hack around it (other than\nmodifying the progress-code, which I consider a somewhat nasty\nalternative).\n\nSo perhaps writing a test to avoid similar breakages in the future isn't\nworth it?\n\n builtin/clone.c |    2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex bbd5c96..a4d8d25 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -569,7 +569,7 @@ static int checkout(void)\n \topts.update = 1;\n \topts.merge = 1;\n \topts.fn = oneway_merge;\n-\topts.verbose_update = (option_verbosity > 0);\n+\topts.verbose_update = (option_verbosity >= 0);\n \topts.src_index = &the_index;\n \topts.dst_index = &the_index;\n \n-- \n1.7.10.msysgit.1\n"},{"id":"191028","messageId":"7vtxzr4vua.fsf@alter.siamese.dyndns.org","threadId":"30460","inReplyTo":"1336418593-2792-1-git-send-email-kusmabite@gmail.com","subject":"Re: [PATCH] clone: fix progress-regression","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-05-07T19:47:25Z","receivedAt":"2012-05-07T19:47:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Erik Faye-Lund <kusmabite@gmail.com> writes:\n\n> In 5bd631b3 (\"clone: support multiple levels of verbosity\"), the\n> default behavior to show progress of the implicit checkout in\n> the clone-command regressed so that progress was only shown if\n> the verbose-option was specified.\n>\n> Fix this by making option_verbosity == 0 output progress as well.\n>\n> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>\n> ---\n\nThanks.\n\n> Hmpf. While tidying this up for a proper submission, I found out that\n> writing a reliable test is tricky due to the start_progress_delay-usage.\n> I'd have to clone a repo that does not progress more than 50% of the\n> checkout-operation within one second or something like that (I didn't\n> quite follow the logic there), which is a lot :P.\n\nIn real life, most of the checkout is fairly quick for even projects like\nthe kernel, and the logic is an attempt to avoid cluttering the terminal\nwith progress unless it takes unusually long and might make the user feel\nworried.\n\n> So perhaps writing a test to avoid similar breakages in the future isn't\n> worth it?\n\nI agree that it probably isn't worth it, given that it took forever for\nanybody to even complain about this.\n"},{"id":"191066","messageId":"4FA8B34A.2050204@viscovery.net","threadId":"30460","inReplyTo":"7vtxzr4vua.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] clone: fix progress-regression","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-05-08T05:46:50Z","receivedAt":"2012-05-08T05:46:50Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 5/7/2012 21:47, schrieb Junio C Hamano:\n> In real life, most of the checkout is fairly quick for even projects like\n> the kernel, and the logic is an attempt to avoid cluttering the terminal\n> with progress unless it takes unusually long and might make the user feel\n> worried.\n\nWhat is \"unusually long\"? On Windows, it can take its time to switch a\nbranch even if only a few dozen files are affected, the disk cache is\ncold, and an on-access virus scanner is active. :-)\n\nI appreciate the checkout progress indicator as eye candy every once in a\nwhile.\n\n-- Hannes\n"}]}