2007-10-30 20:41:13 +01:00
|
|
|
/*
|
|
|
|
* Simple text-based progress display module for GIT
|
|
|
|
*
|
2009-09-14 08:41:16 +02:00
|
|
|
* Copyright (c) 2007 by Nicolas Pitre <nico@fluxnic.net>
|
2007-10-30 20:41:13 +01:00
|
|
|
*
|
|
|
|
* This code is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
2020-04-27 16:22:37 +02:00
|
|
|
#define GIT_TEST_PROGRESS_ONLY
|
progress: break too long progress bar lines
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar exceeds the width of the terminal it gets
line-wrapped, and after that the CR at the end doesn't return to the
beginning of the progress bar, but to the first column of its last
line. Consequently, the first line of the previously shown progress
bar is not overwritten by the next, and we end up with a bunch of
truncated progress bar lines scrolling past:
$ LANG=es_ES.UTF-8 git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados: 2% (1599
Encontrando commits para commit graph entre los objetos empaquetados: 3% (1975
Encontrando commits para commit graph entre los objetos empaquetados: 4% (2633
Encontrando commits para commit graph entre los objetos empaquetados: 5% (3292
[...]
Prevent this by breaking progress bars after the title once they
exceed the width of the terminal, so the counter and optional
percentage and throughput, i.e. all changing parts, are on the last
line. Subsequent updates will from then on only refresh the changing
parts, but not the title, and it will look like this:
$ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados:
100% (6584502/6584502), listo.
Calculando números de generación de commit graph: 100% (824705/824705), listo.
Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo.
Note that the number of columns in the terminal is cached by
term_columns(), so this might not kick in when it should when a
terminal window is resized while the operation is running.
Furthermore, this change won't help if the terminal is so narrow that
the counters don't fit on one line, but I would put this in the "If it
hurts, don't do it" box.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 21:45:15 +02:00
|
|
|
#include "cache.h"
|
2014-02-21 13:50:18 +01:00
|
|
|
#include "gettext.h"
|
2007-04-18 20:27:45 +02:00
|
|
|
#include "progress.h"
|
2013-04-10 21:03:23 +02:00
|
|
|
#include "strbuf.h"
|
2014-07-12 02:08:11 +02:00
|
|
|
#include "trace.h"
|
progress: break too long progress bar lines
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar exceeds the width of the terminal it gets
line-wrapped, and after that the CR at the end doesn't return to the
beginning of the progress bar, but to the first column of its last
line. Consequently, the first line of the previously shown progress
bar is not overwritten by the next, and we end up with a bunch of
truncated progress bar lines scrolling past:
$ LANG=es_ES.UTF-8 git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados: 2% (1599
Encontrando commits para commit graph entre los objetos empaquetados: 3% (1975
Encontrando commits para commit graph entre los objetos empaquetados: 4% (2633
Encontrando commits para commit graph entre los objetos empaquetados: 5% (3292
[...]
Prevent this by breaking progress bars after the title once they
exceed the width of the terminal, so the counter and optional
percentage and throughput, i.e. all changing parts, are on the last
line. Subsequent updates will from then on only refresh the changing
parts, but not the title, and it will look like this:
$ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados:
100% (6584502/6584502), listo.
Calculando números de generación de commit graph: 100% (824705/824705), listo.
Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo.
Note that the number of columns in the terminal is cached by
term_columns(), so this might not kick in when it should when a
terminal window is resized while the operation is running.
Furthermore, this change won't help if the terminal is so narrow that
the counters don't fit on one line, but I would put this in the "If it
hurts, don't do it" box.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 21:45:15 +02:00
|
|
|
#include "utf8.h"
|
2019-11-25 22:28:22 +01:00
|
|
|
#include "config.h"
|
2007-04-18 20:27:45 +02:00
|
|
|
|
2007-10-30 19:57:34 +01:00
|
|
|
#define TP_IDX_MAX 8
|
|
|
|
|
|
|
|
struct throughput {
|
2007-11-06 22:30:28 +01:00
|
|
|
off_t curr_total;
|
2007-11-05 04:15:41 +01:00
|
|
|
off_t prev_total;
|
2014-07-12 02:08:11 +02:00
|
|
|
uint64_t prev_ns;
|
2007-11-05 04:15:41 +01:00
|
|
|
unsigned int avg_bytes;
|
2007-10-30 19:57:34 +01:00
|
|
|
unsigned int avg_misecs;
|
2007-11-06 22:30:28 +01:00
|
|
|
unsigned int last_bytes[TP_IDX_MAX];
|
2007-10-30 19:57:34 +01:00
|
|
|
unsigned int last_misecs[TP_IDX_MAX];
|
|
|
|
unsigned int idx;
|
2015-09-24 23:05:57 +02:00
|
|
|
struct strbuf display;
|
2007-10-30 19:57:34 +01:00
|
|
|
};
|
|
|
|
|
2007-10-30 19:57:32 +01:00
|
|
|
struct progress {
|
|
|
|
const char *title;
|
2017-11-13 21:15:58 +01:00
|
|
|
uint64_t last_value;
|
|
|
|
uint64_t total;
|
2007-10-30 19:57:32 +01:00
|
|
|
unsigned last_percent;
|
|
|
|
unsigned delay;
|
2019-03-21 20:36:11 +01:00
|
|
|
unsigned sparse;
|
2007-10-30 19:57:34 +01:00
|
|
|
struct throughput *throughput;
|
2017-07-08 18:43:42 +02:00
|
|
|
uint64_t start_ns;
|
2019-04-05 02:45:37 +02:00
|
|
|
struct strbuf counters_sb;
|
progress: break too long progress bar lines
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar exceeds the width of the terminal it gets
line-wrapped, and after that the CR at the end doesn't return to the
beginning of the progress bar, but to the first column of its last
line. Consequently, the first line of the previously shown progress
bar is not overwritten by the next, and we end up with a bunch of
truncated progress bar lines scrolling past:
$ LANG=es_ES.UTF-8 git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados: 2% (1599
Encontrando commits para commit graph entre los objetos empaquetados: 3% (1975
Encontrando commits para commit graph entre los objetos empaquetados: 4% (2633
Encontrando commits para commit graph entre los objetos empaquetados: 5% (3292
[...]
Prevent this by breaking progress bars after the title once they
exceed the width of the terminal, so the counter and optional
percentage and throughput, i.e. all changing parts, are on the last
line. Subsequent updates will from then on only refresh the changing
parts, but not the title, and it will look like this:
$ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados:
100% (6584502/6584502), listo.
Calculando números de generación de commit graph: 100% (824705/824705), listo.
Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo.
Note that the number of columns in the terminal is cached by
term_columns(), so this might not kick in when it should when a
terminal window is resized while the operation is running.
Furthermore, this change won't help if the terminal is so narrow that
the counters don't fit on one line, but I would put this in the "If it
hurts, don't do it" box.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 21:45:15 +02:00
|
|
|
int title_len;
|
|
|
|
int split;
|
2007-10-30 19:57:32 +01:00
|
|
|
};
|
|
|
|
|
2007-04-18 20:27:45 +02:00
|
|
|
static volatile sig_atomic_t progress_update;
|
|
|
|
|
Test the progress display
'progress.c' has seen a few fixes recently [1], and, unfortunately,
some of those fixes required further fixes [2]. It seems it's time to
have a few tests focusing on the subtleties of the progress display.
Add the 'test-tool progress' subcommand to help testing the progress
display, reading instructions from standard input and turning them
into calls to the display_progress() and display_throughput()
functions with the given parameters.
The progress display is, however, critically dependent on timing,
because it's only updated once every second or, if the toal is known
in advance, every 1%, and there is the throughput rate as well. These
make the progress display far too undeterministic for testing as-is.
To address this, add a few testing-specific variables and functions to
'progress.c', allowing the the new test helper to:
- Disable the triggered-every-second SIGALRM and set the
'progress_update' flag explicitly based in the input instructions.
This way the progress line will be updated deterministically when
the test wants it to be updated.
- Specify the time elapsed since start_progress() to make the
throughput rate calculations deterministic.
Add the new test script 't0500-progress-display.sh' to check a few
simple cases with and without throughput, and that a shorter progress
line properly covers up the previously displayed line in different
situations.
[1] See commits 545dc345eb (progress: break too long progress bar
lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous
progress update dynamically, 2019-04-12).
[2] 1aed1a5f25 (progress: avoid empty line when breaking the progress
line, 2019-05-19)
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:12 +02:00
|
|
|
/*
|
|
|
|
* These are only intended for testing the progress output, i.e. exclusively
|
|
|
|
* for 'test-tool progress'.
|
|
|
|
*/
|
|
|
|
int progress_testing;
|
|
|
|
uint64_t progress_test_ns = 0;
|
|
|
|
void progress_test_force_update(void)
|
|
|
|
{
|
|
|
|
progress_update = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-04-18 20:27:45 +02:00
|
|
|
static void progress_interval(int signum)
|
|
|
|
{
|
|
|
|
progress_update = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_progress_signal(void)
|
|
|
|
{
|
|
|
|
struct sigaction sa;
|
|
|
|
struct itimerval v;
|
|
|
|
|
Test the progress display
'progress.c' has seen a few fixes recently [1], and, unfortunately,
some of those fixes required further fixes [2]. It seems it's time to
have a few tests focusing on the subtleties of the progress display.
Add the 'test-tool progress' subcommand to help testing the progress
display, reading instructions from standard input and turning them
into calls to the display_progress() and display_throughput()
functions with the given parameters.
The progress display is, however, critically dependent on timing,
because it's only updated once every second or, if the toal is known
in advance, every 1%, and there is the throughput rate as well. These
make the progress display far too undeterministic for testing as-is.
To address this, add a few testing-specific variables and functions to
'progress.c', allowing the the new test helper to:
- Disable the triggered-every-second SIGALRM and set the
'progress_update' flag explicitly based in the input instructions.
This way the progress line will be updated deterministically when
the test wants it to be updated.
- Specify the time elapsed since start_progress() to make the
throughput rate calculations deterministic.
Add the new test script 't0500-progress-display.sh' to check a few
simple cases with and without throughput, and that a shorter progress
line properly covers up the previously displayed line in different
situations.
[1] See commits 545dc345eb (progress: break too long progress bar
lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous
progress update dynamically, 2019-04-12).
[2] 1aed1a5f25 (progress: avoid empty line when breaking the progress
line, 2019-05-19)
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:12 +02:00
|
|
|
if (progress_testing)
|
|
|
|
return;
|
|
|
|
|
2007-04-20 21:05:27 +02:00
|
|
|
progress_update = 0;
|
|
|
|
|
2007-04-18 20:27:45 +02:00
|
|
|
memset(&sa, 0, sizeof(sa));
|
|
|
|
sa.sa_handler = progress_interval;
|
|
|
|
sigemptyset(&sa.sa_mask);
|
|
|
|
sa.sa_flags = SA_RESTART;
|
|
|
|
sigaction(SIGALRM, &sa, NULL);
|
|
|
|
|
|
|
|
v.it_interval.tv_sec = 1;
|
|
|
|
v.it_interval.tv_usec = 0;
|
|
|
|
v.it_value = v.it_interval;
|
|
|
|
setitimer(ITIMER_REAL, &v, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void clear_progress_signal(void)
|
|
|
|
{
|
|
|
|
struct itimerval v = {{0,},};
|
Test the progress display
'progress.c' has seen a few fixes recently [1], and, unfortunately,
some of those fixes required further fixes [2]. It seems it's time to
have a few tests focusing on the subtleties of the progress display.
Add the 'test-tool progress' subcommand to help testing the progress
display, reading instructions from standard input and turning them
into calls to the display_progress() and display_throughput()
functions with the given parameters.
The progress display is, however, critically dependent on timing,
because it's only updated once every second or, if the toal is known
in advance, every 1%, and there is the throughput rate as well. These
make the progress display far too undeterministic for testing as-is.
To address this, add a few testing-specific variables and functions to
'progress.c', allowing the the new test helper to:
- Disable the triggered-every-second SIGALRM and set the
'progress_update' flag explicitly based in the input instructions.
This way the progress line will be updated deterministically when
the test wants it to be updated.
- Specify the time elapsed since start_progress() to make the
throughput rate calculations deterministic.
Add the new test script 't0500-progress-display.sh' to check a few
simple cases with and without throughput, and that a shorter progress
line properly covers up the previously displayed line in different
situations.
[1] See commits 545dc345eb (progress: break too long progress bar
lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous
progress update dynamically, 2019-04-12).
[2] 1aed1a5f25 (progress: avoid empty line when breaking the progress
line, 2019-05-19)
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:12 +02:00
|
|
|
|
|
|
|
if (progress_testing)
|
|
|
|
return;
|
|
|
|
|
2007-04-18 20:27:45 +02:00
|
|
|
setitimer(ITIMER_REAL, &v, NULL);
|
|
|
|
signal(SIGALRM, SIG_IGN);
|
|
|
|
progress_update = 0;
|
|
|
|
}
|
|
|
|
|
2015-04-13 15:30:51 +02:00
|
|
|
static int is_foreground_fd(int fd)
|
|
|
|
{
|
2015-05-19 07:24:57 +02:00
|
|
|
int tpgrp = tcgetpgrp(fd);
|
|
|
|
return tpgrp < 0 || tpgrp == getpgid(0);
|
2015-04-13 15:30:51 +02:00
|
|
|
}
|
|
|
|
|
progress: make display_progress() return void
Ever since the progress infrastructure was introduced in 96a02f8f6d
(common progress display support, 2007-04-18), display_progress() has
returned an int, telling callers whether it updated the progress bar
or not. However, this is:
- useless, because over the last dozen years there has never been a
single caller that cared about that return value.
- not quite true, because it doesn't print a progress bar when
running in the background, yet it returns 1; see 85cb8906f0
(progress: no progress in background, 2015-04-13).
The related display_throughput() function returned void already upon
its introduction in cf84d51c43 (add throughput to progress display,
2007-10-30).
Let's make display_progress() return void, too. While doing so
several return statements in display() become unnecessary, remove
them.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-05 02:45:36 +02:00
|
|
|
static void display(struct progress *progress, uint64_t n, const char *done)
|
2007-04-18 20:27:45 +02:00
|
|
|
{
|
2019-04-05 02:45:37 +02:00
|
|
|
const char *tp;
|
|
|
|
struct strbuf *counters_sb = &progress->counters_sb;
|
|
|
|
int show_update = 0;
|
Revert "progress: use term_clear_line()"
This reverts commit 5b12e3123b (progress: use term_clear_line(),
2019-06-24), because covering up the entire last line while refreshing
the progress line caused unexpected problems during 'git
clone/fetch/push':
$ git clone ssh://localhost/home/szeder/src/tmp/linux.git/
Cloning into 'linux'...
remote:
remote:
remote:
remote: Enumerating objects: 999295
The length of the progress bar line can shorten when it includes
throughput and the unit changes, or when its length exceeds the width
of the terminal and is broken into two lines. In these cases the
previously displayed longer progress line should be covered up,
because otherwise the leftover characters from the previous progress
line make the output look weird [1]. term_clear_line() makes this
quite simple, as it covers up the entire last line either by using an
ANSI control sequence or by printing a terminal width worth of space
characters, depending on whether the terminal is smart or dumb.
Unfortunately, when accessing a remote repository via any non-local
protocol the remote 'git receive-pack/upload-pack' processes can't
possibly have any idea about the local terminal (smart of dumb? how
wide?) their progress will end up on. Consequently, they assume the
worst, i.e. standard-width dumb terminal, and print 80 spaces to cover
up the previously displayed progress line. The local 'git
clone/fetch/push' processes then display the remote's progress,
including these coverup spaces, with the 'remote: ' prefix, resulting
in a total line length of 88 characters. If the local terminal is
narrower than that, then the coverup gets line-wrapped, and after that
the CR at the end doesn't return to the beginning of the progress
line, but to the first column of its last line, resulting in those
repeated 'remote: <many-spaces>' lines.
By reverting 5b12e3123b (progress: use term_clear_line(),
2019-06-24) we won't cover up the entire last line, but go back to
comparing the length of the current progress bar line with the
previous one, and cover up as many characters as needed.
[1] See commits 545dc345eb (progress: break too long progress bar
lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous
progress update dynamically, 2019-04-12).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:11 +02:00
|
|
|
int last_count_len = counters_sb->len;
|
2007-10-17 03:55:45 +02:00
|
|
|
|
2017-12-04 23:07:00 +01:00
|
|
|
if (progress->delay && (!progress_update || --progress->delay))
|
progress: make display_progress() return void
Ever since the progress infrastructure was introduced in 96a02f8f6d
(common progress display support, 2007-04-18), display_progress() has
returned an int, telling callers whether it updated the progress bar
or not. However, this is:
- useless, because over the last dozen years there has never been a
single caller that cared about that return value.
- not quite true, because it doesn't print a progress bar when
running in the background, yet it returns 1; see 85cb8906f0
(progress: no progress in background, 2015-04-13).
The related display_throughput() function returned void already upon
its introduction in cf84d51c43 (add throughput to progress display,
2007-10-30).
Let's make display_progress() return void, too. While doing so
several return statements in display() become unnecessary, remove
them.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-05 02:45:36 +02:00
|
|
|
return;
|
2007-10-17 03:55:45 +02:00
|
|
|
|
|
|
|
progress->last_value = n;
|
2015-09-24 23:05:57 +02:00
|
|
|
tp = (progress->throughput) ? progress->throughput->display.buf : "";
|
2007-04-18 20:27:45 +02:00
|
|
|
if (progress->total) {
|
|
|
|
unsigned percent = n * 100 / progress->total;
|
|
|
|
if (percent != progress->last_percent || progress_update) {
|
|
|
|
progress->last_percent = percent;
|
2019-04-05 02:45:37 +02:00
|
|
|
|
|
|
|
strbuf_reset(counters_sb);
|
|
|
|
strbuf_addf(counters_sb,
|
|
|
|
"%3u%% (%"PRIuMAX"/%"PRIuMAX")%s", percent,
|
|
|
|
(uintmax_t)n, (uintmax_t)progress->total,
|
|
|
|
tp);
|
|
|
|
show_update = 1;
|
2007-04-18 20:27:45 +02:00
|
|
|
}
|
|
|
|
} else if (progress_update) {
|
2019-04-05 02:45:37 +02:00
|
|
|
strbuf_reset(counters_sb);
|
|
|
|
strbuf_addf(counters_sb, "%"PRIuMAX"%s", (uintmax_t)n, tp);
|
|
|
|
show_update = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (show_update) {
|
2015-04-13 15:30:51 +02:00
|
|
|
if (is_foreground_fd(fileno(stderr)) || done) {
|
progress: clear previous progress update dynamically
When the progress bar includes throughput, its length can shorten as
the unit of display changes from KiB to MiB. To cover up remnants of
the previous progress bar when such a change of units happens we
always print three spaces at the end of the progress bar.
Alas, covering only three characters is not quite enough: when both
the total and the throughput happen to change units from KiB to MiB in
the same update, then the progress bar's length is shortened by four
characters (or maybe even more!):
Receiving objects: 25% (2901/11603), 772.01 KiB | 733.00 KiB/s
Receiving objects: 27% (3133/11603), 1.43 MiB | 1.16 MiB/s s
and a stray 's' is left behind.
So instead of hard-coding the three characters to cover, let's compare
the length of the current progress bar with the previous one, and
cover up as many characters as needed.
Sure, it would be much simpler to just print more spaces at the end of
the progress bar, but this approach is more future-proof, and it won't
print extra spaces when none are needed, notably when the progress bar
doesn't show throughput and thus never shrinks.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 21:45:14 +02:00
|
|
|
const char *eol = done ? done : "\r";
|
Revert "progress: use term_clear_line()"
This reverts commit 5b12e3123b (progress: use term_clear_line(),
2019-06-24), because covering up the entire last line while refreshing
the progress line caused unexpected problems during 'git
clone/fetch/push':
$ git clone ssh://localhost/home/szeder/src/tmp/linux.git/
Cloning into 'linux'...
remote:
remote:
remote:
remote: Enumerating objects: 999295
The length of the progress bar line can shorten when it includes
throughput and the unit changes, or when its length exceeds the width
of the terminal and is broken into two lines. In these cases the
previously displayed longer progress line should be covered up,
because otherwise the leftover characters from the previous progress
line make the output look weird [1]. term_clear_line() makes this
quite simple, as it covers up the entire last line either by using an
ANSI control sequence or by printing a terminal width worth of space
characters, depending on whether the terminal is smart or dumb.
Unfortunately, when accessing a remote repository via any non-local
protocol the remote 'git receive-pack/upload-pack' processes can't
possibly have any idea about the local terminal (smart of dumb? how
wide?) their progress will end up on. Consequently, they assume the
worst, i.e. standard-width dumb terminal, and print 80 spaces to cover
up the previously displayed progress line. The local 'git
clone/fetch/push' processes then display the remote's progress,
including these coverup spaces, with the 'remote: ' prefix, resulting
in a total line length of 88 characters. If the local terminal is
narrower than that, then the coverup gets line-wrapped, and after that
the CR at the end doesn't return to the beginning of the progress
line, but to the first column of its last line, resulting in those
repeated 'remote: <many-spaces>' lines.
By reverting 5b12e3123b (progress: use term_clear_line(),
2019-06-24) we won't cover up the entire last line, but go back to
comparing the length of the current progress bar line with the
previous one, and cover up as many characters as needed.
[1] See commits 545dc345eb (progress: break too long progress bar
lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous
progress update dynamically, 2019-04-12).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:11 +02:00
|
|
|
size_t clear_len = counters_sb->len < last_count_len ?
|
|
|
|
last_count_len - counters_sb->len + 1 :
|
|
|
|
0;
|
|
|
|
/* The "+ 2" accounts for the ": ". */
|
|
|
|
size_t progress_line_len = progress->title_len +
|
|
|
|
counters_sb->len + 2;
|
|
|
|
int cols = term_columns();
|
progress: break too long progress bar lines
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar exceeds the width of the terminal it gets
line-wrapped, and after that the CR at the end doesn't return to the
beginning of the progress bar, but to the first column of its last
line. Consequently, the first line of the previously shown progress
bar is not overwritten by the next, and we end up with a bunch of
truncated progress bar lines scrolling past:
$ LANG=es_ES.UTF-8 git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados: 2% (1599
Encontrando commits para commit graph entre los objetos empaquetados: 3% (1975
Encontrando commits para commit graph entre los objetos empaquetados: 4% (2633
Encontrando commits para commit graph entre los objetos empaquetados: 5% (3292
[...]
Prevent this by breaking progress bars after the title once they
exceed the width of the terminal, so the counter and optional
percentage and throughput, i.e. all changing parts, are on the last
line. Subsequent updates will from then on only refresh the changing
parts, but not the title, and it will look like this:
$ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados:
100% (6584502/6584502), listo.
Calculando números de generación de commit graph: 100% (824705/824705), listo.
Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo.
Note that the number of columns in the terminal is cached by
term_columns(), so this might not kick in when it should when a
terminal window is resized while the operation is running.
Furthermore, this change won't help if the terminal is so narrow that
the counters don't fit on one line, but I would put this in the "If it
hurts, don't do it" box.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 21:45:15 +02:00
|
|
|
|
|
|
|
if (progress->split) {
|
Revert "progress: use term_clear_line()"
This reverts commit 5b12e3123b (progress: use term_clear_line(),
2019-06-24), because covering up the entire last line while refreshing
the progress line caused unexpected problems during 'git
clone/fetch/push':
$ git clone ssh://localhost/home/szeder/src/tmp/linux.git/
Cloning into 'linux'...
remote:
remote:
remote:
remote: Enumerating objects: 999295
The length of the progress bar line can shorten when it includes
throughput and the unit changes, or when its length exceeds the width
of the terminal and is broken into two lines. In these cases the
previously displayed longer progress line should be covered up,
because otherwise the leftover characters from the previous progress
line make the output look weird [1]. term_clear_line() makes this
quite simple, as it covers up the entire last line either by using an
ANSI control sequence or by printing a terminal width worth of space
characters, depending on whether the terminal is smart or dumb.
Unfortunately, when accessing a remote repository via any non-local
protocol the remote 'git receive-pack/upload-pack' processes can't
possibly have any idea about the local terminal (smart of dumb? how
wide?) their progress will end up on. Consequently, they assume the
worst, i.e. standard-width dumb terminal, and print 80 spaces to cover
up the previously displayed progress line. The local 'git
clone/fetch/push' processes then display the remote's progress,
including these coverup spaces, with the 'remote: ' prefix, resulting
in a total line length of 88 characters. If the local terminal is
narrower than that, then the coverup gets line-wrapped, and after that
the CR at the end doesn't return to the beginning of the progress
line, but to the first column of its last line, resulting in those
repeated 'remote: <many-spaces>' lines.
By reverting 5b12e3123b (progress: use term_clear_line(),
2019-06-24) we won't cover up the entire last line, but go back to
comparing the length of the current progress bar line with the
previous one, and cover up as many characters as needed.
[1] See commits 545dc345eb (progress: break too long progress bar
lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous
progress update dynamically, 2019-04-12).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:11 +02:00
|
|
|
fprintf(stderr, " %s%*s", counters_sb->buf,
|
|
|
|
(int) clear_len, eol);
|
|
|
|
} else if (!done && cols < progress_line_len) {
|
|
|
|
clear_len = progress->title_len + 1 < cols ?
|
|
|
|
cols - progress->title_len - 1 : 0;
|
|
|
|
fprintf(stderr, "%s:%*s\n %s%s",
|
|
|
|
progress->title, (int) clear_len, "",
|
|
|
|
counters_sb->buf, eol);
|
progress: break too long progress bar lines
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar exceeds the width of the terminal it gets
line-wrapped, and after that the CR at the end doesn't return to the
beginning of the progress bar, but to the first column of its last
line. Consequently, the first line of the previously shown progress
bar is not overwritten by the next, and we end up with a bunch of
truncated progress bar lines scrolling past:
$ LANG=es_ES.UTF-8 git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados: 2% (1599
Encontrando commits para commit graph entre los objetos empaquetados: 3% (1975
Encontrando commits para commit graph entre los objetos empaquetados: 4% (2633
Encontrando commits para commit graph entre los objetos empaquetados: 5% (3292
[...]
Prevent this by breaking progress bars after the title once they
exceed the width of the terminal, so the counter and optional
percentage and throughput, i.e. all changing parts, are on the last
line. Subsequent updates will from then on only refresh the changing
parts, but not the title, and it will look like this:
$ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados:
100% (6584502/6584502), listo.
Calculando números de generación de commit graph: 100% (824705/824705), listo.
Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo.
Note that the number of columns in the terminal is cached by
term_columns(), so this might not kick in when it should when a
terminal window is resized while the operation is running.
Furthermore, this change won't help if the terminal is so narrow that
the counters don't fit on one line, but I would put this in the "If it
hurts, don't do it" box.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 21:45:15 +02:00
|
|
|
progress->split = 1;
|
|
|
|
} else {
|
Revert "progress: use term_clear_line()"
This reverts commit 5b12e3123b (progress: use term_clear_line(),
2019-06-24), because covering up the entire last line while refreshing
the progress line caused unexpected problems during 'git
clone/fetch/push':
$ git clone ssh://localhost/home/szeder/src/tmp/linux.git/
Cloning into 'linux'...
remote:
remote:
remote:
remote: Enumerating objects: 999295
The length of the progress bar line can shorten when it includes
throughput and the unit changes, or when its length exceeds the width
of the terminal and is broken into two lines. In these cases the
previously displayed longer progress line should be covered up,
because otherwise the leftover characters from the previous progress
line make the output look weird [1]. term_clear_line() makes this
quite simple, as it covers up the entire last line either by using an
ANSI control sequence or by printing a terminal width worth of space
characters, depending on whether the terminal is smart or dumb.
Unfortunately, when accessing a remote repository via any non-local
protocol the remote 'git receive-pack/upload-pack' processes can't
possibly have any idea about the local terminal (smart of dumb? how
wide?) their progress will end up on. Consequently, they assume the
worst, i.e. standard-width dumb terminal, and print 80 spaces to cover
up the previously displayed progress line. The local 'git
clone/fetch/push' processes then display the remote's progress,
including these coverup spaces, with the 'remote: ' prefix, resulting
in a total line length of 88 characters. If the local terminal is
narrower than that, then the coverup gets line-wrapped, and after that
the CR at the end doesn't return to the beginning of the progress
line, but to the first column of its last line, resulting in those
repeated 'remote: <many-spaces>' lines.
By reverting 5b12e3123b (progress: use term_clear_line(),
2019-06-24) we won't cover up the entire last line, but go back to
comparing the length of the current progress bar line with the
previous one, and cover up as many characters as needed.
[1] See commits 545dc345eb (progress: break too long progress bar
lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous
progress update dynamically, 2019-04-12).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:11 +02:00
|
|
|
fprintf(stderr, "%s: %s%*s", progress->title,
|
|
|
|
counters_sb->buf, (int) clear_len, eol);
|
progress: break too long progress bar lines
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar exceeds the width of the terminal it gets
line-wrapped, and after that the CR at the end doesn't return to the
beginning of the progress bar, but to the first column of its last
line. Consequently, the first line of the previously shown progress
bar is not overwritten by the next, and we end up with a bunch of
truncated progress bar lines scrolling past:
$ LANG=es_ES.UTF-8 git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados: 2% (1599
Encontrando commits para commit graph entre los objetos empaquetados: 3% (1975
Encontrando commits para commit graph entre los objetos empaquetados: 4% (2633
Encontrando commits para commit graph entre los objetos empaquetados: 5% (3292
[...]
Prevent this by breaking progress bars after the title once they
exceed the width of the terminal, so the counter and optional
percentage and throughput, i.e. all changing parts, are on the last
line. Subsequent updates will from then on only refresh the changing
parts, but not the title, and it will look like this:
$ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados:
100% (6584502/6584502), listo.
Calculando números de generación de commit graph: 100% (824705/824705), listo.
Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo.
Note that the number of columns in the terminal is cached by
term_columns(), so this might not kick in when it should when a
terminal window is resized while the operation is running.
Furthermore, this change won't help if the terminal is so narrow that
the counters don't fit on one line, but I would put this in the "If it
hurts, don't do it" box.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 21:45:15 +02:00
|
|
|
}
|
2015-04-13 15:30:51 +02:00
|
|
|
fflush(stderr);
|
|
|
|
}
|
2007-04-18 20:27:45 +02:00
|
|
|
progress_update = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-13 21:15:58 +01:00
|
|
|
static void throughput_string(struct strbuf *buf, uint64_t total,
|
2007-11-06 22:30:28 +01:00
|
|
|
unsigned int rate)
|
|
|
|
{
|
2015-09-24 23:05:57 +02:00
|
|
|
strbuf_reset(buf);
|
2013-04-10 21:03:23 +02:00
|
|
|
strbuf_addstr(buf, ", ");
|
|
|
|
strbuf_humanise_bytes(buf, total);
|
|
|
|
strbuf_addstr(buf, " | ");
|
2019-07-02 20:22:48 +02:00
|
|
|
strbuf_humanise_rate(buf, rate * 1024);
|
2007-11-06 22:30:28 +01:00
|
|
|
}
|
|
|
|
|
Test the progress display
'progress.c' has seen a few fixes recently [1], and, unfortunately,
some of those fixes required further fixes [2]. It seems it's time to
have a few tests focusing on the subtleties of the progress display.
Add the 'test-tool progress' subcommand to help testing the progress
display, reading instructions from standard input and turning them
into calls to the display_progress() and display_throughput()
functions with the given parameters.
The progress display is, however, critically dependent on timing,
because it's only updated once every second or, if the toal is known
in advance, every 1%, and there is the throughput rate as well. These
make the progress display far too undeterministic for testing as-is.
To address this, add a few testing-specific variables and functions to
'progress.c', allowing the the new test helper to:
- Disable the triggered-every-second SIGALRM and set the
'progress_update' flag explicitly based in the input instructions.
This way the progress line will be updated deterministically when
the test wants it to be updated.
- Specify the time elapsed since start_progress() to make the
throughput rate calculations deterministic.
Add the new test script 't0500-progress-display.sh' to check a few
simple cases with and without throughput, and that a shorter progress
line properly covers up the previously displayed line in different
situations.
[1] See commits 545dc345eb (progress: break too long progress bar
lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous
progress update dynamically, 2019-04-12).
[2] 1aed1a5f25 (progress: avoid empty line when breaking the progress
line, 2019-05-19)
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:12 +02:00
|
|
|
static uint64_t progress_getnanotime(struct progress *progress)
|
|
|
|
{
|
|
|
|
if (progress_testing)
|
|
|
|
return progress->start_ns + progress_test_ns;
|
|
|
|
else
|
|
|
|
return getnanotime();
|
|
|
|
}
|
|
|
|
|
2017-11-13 21:15:58 +01:00
|
|
|
void display_throughput(struct progress *progress, uint64_t total)
|
2007-10-30 19:57:34 +01:00
|
|
|
{
|
|
|
|
struct throughput *tp;
|
2014-07-12 02:08:11 +02:00
|
|
|
uint64_t now_ns;
|
|
|
|
unsigned int misecs, count, rate;
|
2007-10-30 19:57:34 +01:00
|
|
|
|
|
|
|
if (!progress)
|
|
|
|
return;
|
|
|
|
tp = progress->throughput;
|
|
|
|
|
Test the progress display
'progress.c' has seen a few fixes recently [1], and, unfortunately,
some of those fixes required further fixes [2]. It seems it's time to
have a few tests focusing on the subtleties of the progress display.
Add the 'test-tool progress' subcommand to help testing the progress
display, reading instructions from standard input and turning them
into calls to the display_progress() and display_throughput()
functions with the given parameters.
The progress display is, however, critically dependent on timing,
because it's only updated once every second or, if the toal is known
in advance, every 1%, and there is the throughput rate as well. These
make the progress display far too undeterministic for testing as-is.
To address this, add a few testing-specific variables and functions to
'progress.c', allowing the the new test helper to:
- Disable the triggered-every-second SIGALRM and set the
'progress_update' flag explicitly based in the input instructions.
This way the progress line will be updated deterministically when
the test wants it to be updated.
- Specify the time elapsed since start_progress() to make the
throughput rate calculations deterministic.
Add the new test script 't0500-progress-display.sh' to check a few
simple cases with and without throughput, and that a shorter progress
line properly covers up the previously displayed line in different
situations.
[1] See commits 545dc345eb (progress: break too long progress bar
lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous
progress update dynamically, 2019-04-12).
[2] 1aed1a5f25 (progress: avoid empty line when breaking the progress
line, 2019-05-19)
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-16 22:54:12 +02:00
|
|
|
now_ns = progress_getnanotime(progress);
|
2007-10-30 19:57:34 +01:00
|
|
|
|
|
|
|
if (!tp) {
|
2021-03-13 17:17:22 +01:00
|
|
|
progress->throughput = CALLOC_ARRAY(tp, 1);
|
2019-04-11 15:49:57 +02:00
|
|
|
tp->prev_total = tp->curr_total = total;
|
|
|
|
tp->prev_ns = now_ns;
|
|
|
|
strbuf_init(&tp->display, 0);
|
2007-10-30 19:57:34 +01:00
|
|
|
return;
|
|
|
|
}
|
2007-11-06 22:30:28 +01:00
|
|
|
tp->curr_total = total;
|
2007-10-30 19:57:34 +01:00
|
|
|
|
2014-07-12 02:08:11 +02:00
|
|
|
/* only update throughput every 0.5 s */
|
|
|
|
if (now_ns - tp->prev_ns <= 500000000)
|
|
|
|
return;
|
|
|
|
|
2007-10-30 19:57:34 +01:00
|
|
|
/*
|
2014-07-12 02:08:11 +02:00
|
|
|
* We have x = bytes and y = nanosecs. We want z = KiB/s:
|
2007-10-30 19:57:34 +01:00
|
|
|
*
|
2014-07-12 02:08:11 +02:00
|
|
|
* z = (x / 1024) / (y / 1000000000)
|
|
|
|
* z = x / y * 1000000000 / 1024
|
|
|
|
* z = x / (y * 1024 / 1000000000)
|
2007-10-30 19:57:34 +01:00
|
|
|
* z = x / y'
|
|
|
|
*
|
|
|
|
* To simplify things we'll keep track of misecs, or 1024th of a sec
|
|
|
|
* obtained with:
|
|
|
|
*
|
2014-07-12 02:08:11 +02:00
|
|
|
* y' = y * 1024 / 1000000000
|
|
|
|
* y' = y * (2^10 / 2^42) * (2^42 / 1000000000)
|
|
|
|
* y' = y / 2^32 * 4398
|
|
|
|
* y' = (y * 4398) >> 32
|
2007-10-30 19:57:34 +01:00
|
|
|
*/
|
2014-07-12 02:08:11 +02:00
|
|
|
misecs = ((now_ns - tp->prev_ns) * 4398) >> 32;
|
|
|
|
|
|
|
|
count = total - tp->prev_total;
|
|
|
|
tp->prev_total = total;
|
|
|
|
tp->prev_ns = now_ns;
|
|
|
|
tp->avg_bytes += count;
|
|
|
|
tp->avg_misecs += misecs;
|
|
|
|
rate = tp->avg_bytes / tp->avg_misecs;
|
|
|
|
tp->avg_bytes -= tp->last_bytes[tp->idx];
|
|
|
|
tp->avg_misecs -= tp->last_misecs[tp->idx];
|
|
|
|
tp->last_bytes[tp->idx] = count;
|
|
|
|
tp->last_misecs[tp->idx] = misecs;
|
|
|
|
tp->idx = (tp->idx + 1) % TP_IDX_MAX;
|
|
|
|
|
2015-09-24 23:05:57 +02:00
|
|
|
throughput_string(&tp->display, total, rate);
|
2014-07-12 02:08:11 +02:00
|
|
|
if (progress->last_value != -1 && progress_update)
|
|
|
|
display(progress, progress->last_value, NULL);
|
2007-10-30 19:57:34 +01:00
|
|
|
}
|
|
|
|
|
progress: make display_progress() return void
Ever since the progress infrastructure was introduced in 96a02f8f6d
(common progress display support, 2007-04-18), display_progress() has
returned an int, telling callers whether it updated the progress bar
or not. However, this is:
- useless, because over the last dozen years there has never been a
single caller that cared about that return value.
- not quite true, because it doesn't print a progress bar when
running in the background, yet it returns 1; see 85cb8906f0
(progress: no progress in background, 2015-04-13).
The related display_throughput() function returned void already upon
its introduction in cf84d51c43 (add throughput to progress display,
2007-10-30).
Let's make display_progress() return void, too. While doing so
several return statements in display() become unnecessary, remove
them.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-05 02:45:36 +02:00
|
|
|
void display_progress(struct progress *progress, uint64_t n)
|
2007-04-18 20:27:45 +02:00
|
|
|
{
|
progress: make display_progress() return void
Ever since the progress infrastructure was introduced in 96a02f8f6d
(common progress display support, 2007-04-18), display_progress() has
returned an int, telling callers whether it updated the progress bar
or not. However, this is:
- useless, because over the last dozen years there has never been a
single caller that cared about that return value.
- not quite true, because it doesn't print a progress bar when
running in the background, yet it returns 1; see 85cb8906f0
(progress: no progress in background, 2015-04-13).
The related display_throughput() function returned void already upon
its introduction in cf84d51c43 (add throughput to progress display,
2007-10-30).
Let's make display_progress() return void, too. While doing so
several return statements in display() become unnecessary, remove
them.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-05 02:45:36 +02:00
|
|
|
if (progress)
|
|
|
|
display(progress, n, NULL);
|
2007-04-18 20:27:45 +02:00
|
|
|
}
|
|
|
|
|
2017-11-13 21:15:58 +01:00
|
|
|
static struct progress *start_progress_delay(const char *title, uint64_t total,
|
2019-03-21 20:36:11 +01:00
|
|
|
unsigned delay, unsigned sparse)
|
2007-04-20 21:05:27 +02:00
|
|
|
{
|
2019-04-11 15:49:57 +02:00
|
|
|
struct progress *progress = xmalloc(sizeof(*progress));
|
2007-10-17 03:55:45 +02:00
|
|
|
progress->title = title;
|
2007-04-20 21:05:27 +02:00
|
|
|
progress->total = total;
|
2007-10-17 03:55:45 +02:00
|
|
|
progress->last_value = -1;
|
2007-04-20 21:05:27 +02:00
|
|
|
progress->last_percent = -1;
|
|
|
|
progress->delay = delay;
|
2019-03-21 20:36:11 +01:00
|
|
|
progress->sparse = sparse;
|
2007-10-30 19:57:34 +01:00
|
|
|
progress->throughput = NULL;
|
2017-07-08 18:43:42 +02:00
|
|
|
progress->start_ns = getnanotime();
|
2019-04-05 02:45:37 +02:00
|
|
|
strbuf_init(&progress->counters_sb, 0);
|
progress: break too long progress bar lines
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar exceeds the width of the terminal it gets
line-wrapped, and after that the CR at the end doesn't return to the
beginning of the progress bar, but to the first column of its last
line. Consequently, the first line of the previously shown progress
bar is not overwritten by the next, and we end up with a bunch of
truncated progress bar lines scrolling past:
$ LANG=es_ES.UTF-8 git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados: 2% (1599
Encontrando commits para commit graph entre los objetos empaquetados: 3% (1975
Encontrando commits para commit graph entre los objetos empaquetados: 4% (2633
Encontrando commits para commit graph entre los objetos empaquetados: 5% (3292
[...]
Prevent this by breaking progress bars after the title once they
exceed the width of the terminal, so the counter and optional
percentage and throughput, i.e. all changing parts, are on the last
line. Subsequent updates will from then on only refresh the changing
parts, but not the title, and it will look like this:
$ LANG=es_ES.UTF-8 ~/src/git/git commit-graph write
Encontrando commits para commit graph entre los objetos empaquetados:
100% (6584502/6584502), listo.
Calculando números de generación de commit graph: 100% (824705/824705), listo.
Escribiendo commit graph en 4 pasos: 100% (3298820/3298820), listo.
Note that the number of columns in the terminal is cached by
term_columns(), so this might not kick in when it should when a
terminal window is resized while the operation is running.
Furthermore, this change won't help if the terminal is so narrow that
the counters don't fit on one line, but I would put this in the "If it
hurts, don't do it" box.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12 21:45:15 +02:00
|
|
|
progress->title_len = utf8_strwidth(title);
|
|
|
|
progress->split = 0;
|
2007-04-20 21:05:27 +02:00
|
|
|
set_progress_signal();
|
2020-05-12 23:44:20 +02:00
|
|
|
trace2_region_enter("progress", title, the_repository);
|
2007-10-30 19:57:32 +01:00
|
|
|
return progress;
|
2007-04-20 21:05:27 +02:00
|
|
|
}
|
|
|
|
|
2019-11-25 22:28:22 +01:00
|
|
|
static int get_default_delay(void)
|
|
|
|
{
|
|
|
|
static int delay_in_secs = -1;
|
|
|
|
|
|
|
|
if (delay_in_secs < 0)
|
|
|
|
delay_in_secs = git_env_ulong("GIT_PROGRESS_DELAY", 2);
|
|
|
|
|
|
|
|
return delay_in_secs;
|
|
|
|
}
|
|
|
|
|
2017-11-13 21:15:58 +01:00
|
|
|
struct progress *start_delayed_progress(const char *title, uint64_t total)
|
progress: simplify "delayed" progress API
We used to expose the full power of the delayed progress API to the
callers, so that they can specify, not just the message to show and
expected total amount of work that is used to compute the percentage
of work performed so far, the percent-threshold parameter P and the
delay-seconds parameter N. The progress meter starts to show at N
seconds into the operation only if we have not yet completed P per-cent
of the total work.
Most callers used either (0%, 2s) or (50%, 1s) as (P, N), but there
are oddballs that chose more random-looking values like 95%.
For a smoother workload, (50%, 1s) would allow us to start showing
the progress meter earlier than (0%, 2s), while keeping the chance
of not showing progress meter for long running operation the same as
the latter. For a task that would take 2s or more to complete, it
is likely that less than half of it would complete within the first
second, if the workload is smooth. But for a spiky workload whose
earlier part is easier, such a setting is likely to fail to show the
progress meter entirely and (0%, 2s) is more appropriate.
But that is merely a theory. Realistically, it is of dubious value
to ask each codepath to carefully consider smoothness of their
workload and specify their own setting by passing two extra
parameters. Let's simplify the API by dropping both parameters and
have everybody use (0%, 2s).
Oh, by the way, the percent-threshold parameter and the structure
member were consistently misspelled, which also is now fixed ;-)
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19 19:39:41 +02:00
|
|
|
{
|
2019-11-25 22:28:22 +01:00
|
|
|
return start_progress_delay(title, total, get_default_delay(), 0);
|
progress: simplify "delayed" progress API
We used to expose the full power of the delayed progress API to the
callers, so that they can specify, not just the message to show and
expected total amount of work that is used to compute the percentage
of work performed so far, the percent-threshold parameter P and the
delay-seconds parameter N. The progress meter starts to show at N
seconds into the operation only if we have not yet completed P per-cent
of the total work.
Most callers used either (0%, 2s) or (50%, 1s) as (P, N), but there
are oddballs that chose more random-looking values like 95%.
For a smoother workload, (50%, 1s) would allow us to start showing
the progress meter earlier than (0%, 2s), while keeping the chance
of not showing progress meter for long running operation the same as
the latter. For a task that would take 2s or more to complete, it
is likely that less than half of it would complete within the first
second, if the workload is smooth. But for a spiky workload whose
earlier part is easier, such a setting is likely to fail to show the
progress meter entirely and (0%, 2s) is more appropriate.
But that is merely a theory. Realistically, it is of dubious value
to ask each codepath to carefully consider smoothness of their
workload and specify their own setting by passing two extra
parameters. Let's simplify the API by dropping both parameters and
have everybody use (0%, 2s).
Oh, by the way, the percent-threshold parameter and the structure
member were consistently misspelled, which also is now fixed ;-)
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19 19:39:41 +02:00
|
|
|
}
|
|
|
|
|
2017-11-13 21:15:58 +01:00
|
|
|
struct progress *start_progress(const char *title, uint64_t total)
|
2007-10-17 03:55:45 +02:00
|
|
|
{
|
2019-03-21 20:36:11 +01:00
|
|
|
return start_progress_delay(title, total, 0, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Here "sparse" means that the caller might use some sampling criteria to
|
|
|
|
* decide when to call display_progress() rather than calling it for every
|
|
|
|
* integer value in[0 .. total). In particular, the caller might not call
|
|
|
|
* display_progress() for the last value in the range.
|
|
|
|
*
|
|
|
|
* When "sparse" is set, stop_progress() will automatically force the done
|
|
|
|
* message to show 100%.
|
|
|
|
*/
|
|
|
|
struct progress *start_sparse_progress(const char *title, uint64_t total)
|
|
|
|
{
|
|
|
|
return start_progress_delay(title, total, 0, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct progress *start_delayed_sparse_progress(const char *title,
|
|
|
|
uint64_t total)
|
|
|
|
{
|
2019-11-25 22:28:22 +01:00
|
|
|
return start_progress_delay(title, total, get_default_delay(), 1);
|
2019-03-21 20:36:11 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static void finish_if_sparse(struct progress *progress)
|
|
|
|
{
|
2022-02-03 22:40:18 +01:00
|
|
|
if (progress->sparse &&
|
2019-03-21 20:36:11 +01:00
|
|
|
progress->last_value != progress->total)
|
|
|
|
display_progress(progress, progress->total);
|
2007-10-17 03:55:45 +02:00
|
|
|
}
|
|
|
|
|
2022-02-03 22:40:17 +01:00
|
|
|
static void force_last_update(struct progress *progress, const char *msg)
|
|
|
|
{
|
|
|
|
char *buf;
|
|
|
|
struct throughput *tp = progress->throughput;
|
|
|
|
|
|
|
|
if (tp) {
|
|
|
|
uint64_t now_ns = progress_getnanotime(progress);
|
|
|
|
unsigned int misecs, rate;
|
|
|
|
misecs = ((now_ns - progress->start_ns) * 4398) >> 32;
|
|
|
|
rate = tp->curr_total / (misecs ? misecs : 1);
|
|
|
|
throughput_string(&tp->display, tp->curr_total, rate);
|
|
|
|
}
|
|
|
|
progress_update = 1;
|
|
|
|
buf = xstrfmt(", %s.\n", msg);
|
|
|
|
display(progress, progress->last_value, buf);
|
|
|
|
free(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void log_trace2(struct progress *progress)
|
|
|
|
{
|
|
|
|
trace2_data_intmax("progress", the_repository, "total_objects",
|
|
|
|
progress->total);
|
|
|
|
|
|
|
|
if (progress->throughput)
|
|
|
|
trace2_data_intmax("progress", the_repository, "total_bytes",
|
|
|
|
progress->throughput->curr_total);
|
|
|
|
|
|
|
|
trace2_region_leave("progress", progress->title, the_repository);
|
|
|
|
}
|
|
|
|
|
2007-11-08 21:45:41 +01:00
|
|
|
void stop_progress_msg(struct progress **p_progress, const char *msg)
|
2007-04-18 20:27:45 +02:00
|
|
|
{
|
progress: don't dereference before checking for NULL
In `stop_progress()`, we're careful to check that `p_progress` is
non-NULL before we dereference it, but by then we have already
dereferenced it when calling `finish_if_sparse(*p_progress)`. And, for
what it's worth, we'll go on to blindly dereference it again inside
`stop_progress_msg()`.
We could return early if we get a NULL-pointer, but let's go one step
further and BUG instead. The progress API handles NULL just fine, but
that's the NULL-ness of `*p_progress`, e.g., when running with
`--no-progress`. If `p_progress` is NULL, chances are that's a mistake.
For symmetry, let's do the same check in `stop_progress_msg()`, too.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-10 21:47:48 +02:00
|
|
|
struct progress *progress;
|
|
|
|
|
|
|
|
if (!p_progress)
|
|
|
|
BUG("don't provide NULL to stop_progress_msg");
|
|
|
|
|
|
|
|
progress = *p_progress;
|
2007-10-30 19:57:32 +01:00
|
|
|
if (!progress)
|
|
|
|
return;
|
|
|
|
*p_progress = NULL;
|
2022-02-03 22:40:17 +01:00
|
|
|
|
2022-02-03 22:40:18 +01:00
|
|
|
finish_if_sparse(progress);
|
2022-02-03 22:40:17 +01:00
|
|
|
if (progress->last_value != -1)
|
|
|
|
force_last_update(progress, msg);
|
2022-02-03 22:40:18 +01:00
|
|
|
log_trace2(progress);
|
2022-02-03 22:40:17 +01:00
|
|
|
|
2007-04-18 20:27:45 +02:00
|
|
|
clear_progress_signal();
|
2019-04-05 02:45:37 +02:00
|
|
|
strbuf_release(&progress->counters_sb);
|
2015-09-24 23:05:57 +02:00
|
|
|
if (progress->throughput)
|
|
|
|
strbuf_release(&progress->throughput->display);
|
2007-10-30 19:57:34 +01:00
|
|
|
free(progress->throughput);
|
2007-10-30 19:57:32 +01:00
|
|
|
free(progress);
|
2007-04-18 20:27:45 +02:00
|
|
|
}
|