git/progress.c, branch gitk-resize-error

use CALLOC_ARRAY

2021-03-14T00:00:09Z

Add and apply a semantic patch for converting code that open-codes CALLOC_ARRAY to use it instead. It shortens the code and infers the element size automatically. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'ma/stop-progress-null-fix'

2020-08-18T00:02:48Z

NULL dereference fix. * ma/stop-progress-null-fix: progress: don't dereference before checking for NULL

progress: don't dereference before checking for NULL

2020-08-10T21:59:57Z

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

progress: call trace2_region_leave() only after calling _enter()

2020-05-15T16:41:30Z

A user of progress API calls start_progress() conditionally and depends on the display_progress() and stop_progress() functions to become no-op when start_progress() hasn't been called. As we added a call to trace2_region_enter() to start_progress(), the calls to other trace2 API calls from the progress API functions must make sure that these trace2 calls are skipped when start_progress() hasn't been called on the progress struct. Specifically, do not call trace2_region_leave() from stop_progress() when we haven't called start_progress(), which would have called the matching trace2_region_enter(). Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

trace2: log progress time and throughput

2020-05-12T22:30:39Z

Rather than teaching only one operation, like 'git fetch', how to write down throughput to traces, we can learn about a wide range of user operations that may seem slow by adding tooling to the progress library itself. Operations which display progress are likely to be slow-running and the kind of thing we want to monitor for performance anyways. By showing object counts and data transfer size, we should be able to make some derived measurements to ensure operations are scaling the way we expect. Signed-off-by: Emily Shaffer Signed-off-by: Junio C Hamano

progress.c: silence cgcc suggestion about internal linkage

2020-04-27T18:21:28Z

Signed-off-by: Đoàn Trần Công Danh Reviewed-by: Ramsay Jones Signed-off-by: Junio C Hamano

progress: create GIT_PROGRESS_DELAY

2019-11-27T01:57:10Z

The start_delayed_progress() method is a preferred way to show optional progress to users as it ignores steps that take less than two seconds. However, this makes testing unreliable as tests expect to be very fast. In addition, users may want to decrease or increase this time interval depending on their preferences for terminal noise. Create the GIT_PROGRESS_DELAY environment variable to control the delay set during start_delayed_progress(). Set the value in some tests to guarantee their output remains consistent. Helped-by: Jeff King Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

Test the progress display

2019-09-17T16:39:16Z

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

Revert "progress: use term_clear_line()"

2019-09-17T16:39:16Z

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

Merge branch 'dr/progress-i18n'

2019-07-11T22:16:49Z

Progress messages have been made localizable. * dr/progress-i18n: l10n: localizable upload progress messages