git/progress.c, branch v2.22.0-rc2

Merge branch 'sg/progress-off-by-one-fix'

2019-05-30T17:50:45Z

A brown-paper-bag bugfix to a change already in 'master'. * sg/progress-off-by-one-fix: progress: avoid empty line when breaking the progress line

progress: avoid empty line when breaking the progress line

2019-05-28T17:21:11Z

Since commit 545dc345eb (progress: break too long progress bar lines, 2019-04-12) when splitting a too long progress line, sometimes it looks as if a superfluous empty line were added between the title line and the counters. To make sure that the previously displayed progress line is completely covered up when writing the new, shorter title line, we calculate how many characters need to be overwritten with spaces. Alas, this calculation doesn't account for the newline character at the end of the new title line, and resulted in printing one more space than strictly necessary. This extra space character doesn't matter, if the length of the previous progress line was shorter than the width of the terminal. However, if the previous line matched the terminal width, then this extra space made the new line longer, effectively adding that empty line after the title line. Fix this off-by-one to avoid that spurious empty line. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

Merge branch 'jk/xmalloc'

2019-04-25T07:41:23Z

The code is updated to check the result of memory allocation before it is used in more places, by using xmalloc and/or xcalloc calls. * jk/xmalloc: progress: use xmalloc/xcalloc xdiff: use xmalloc/xrealloc xdiff: use git-compat-util test-prio-queue: use xmalloc

Merge branch 'sg/overlong-progress-fix'

2019-04-25T07:41:19Z

Updating the display with progress message has been cleaned up to deal better with overlong messages. * sg/overlong-progress-fix: progress: break too long progress bar lines progress: clear previous progress update dynamically progress: assemble percentage and counters in a strbuf before printing progress: make display_progress() return void

progress: break too long progress bar lines

2019-04-15T03:11:25Z

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 Signed-off-by: Junio C Hamano

progress: clear previous progress update dynamically

2019-04-15T03:11:25Z

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 Signed-off-by: Junio C Hamano

progress: use xmalloc/xcalloc

2019-04-12T04:34:17Z

Since the early days of Git, the progress code allocates its struct with a bare malloc(), not xmalloc(). If the allocation fails, we just avoid showing progress at all. While perhaps a noble goal not to fail the whole operation because of optional progress, in practice: 1. Any failure to allocate a few dozen bytes here means critical path allocations are likely to fail, too. 2. These days we use a strbuf for throughput progress (and there's a patch under discussion to do the same for non-throughput cases, too). And that uses xmalloc() under the hood, which means we'd still die on some allocation failures. Let's switch to xmalloc(). That makes us consistent with the rest of Git and makes it easier to audit for other (less careful) bare mallocs. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

progress: assemble percentage and counters in a strbuf before printing

2019-04-05T06:02:06Z

The following patches in this series want to handle the progress bar's title and changing parts (i.e. the counter and the optional percentage and throughput combined) differently, and need to know the length of the changing parts of the previously displayed progress bar. To prepare for those changes assemble the changing parts in a separate strbuf kept in 'struct progress' before printing. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

progress: make display_progress() return void

2019-04-05T06:02:06Z

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 Signed-off-by: Junio C Hamano

progress: add sparse mode to force 100% complete message

2019-03-22T05:31:11Z

Add new start_sparse_progress() and start_delayed_sparse_progress() constructors and "sparse" flag to struct progress. Teach stop_progress() to force a 100% complete progress message before printing the final "done" message when "sparse" is set. Calling display_progress() for every item in a large set can be expensive. If callers try to filter this for performance reasons, such as emitting every k-th item, progress would not reach 100% unless they made a final call to display_progress() with the item count before calling stop_progress(). Now this is automatic when "sparse" is set. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano