git/progress.h, branch jch

progress: stop using `the_repository`

2024-12-18T18:44:30Z

Stop using `the_repository` in the "progress" subsystem by passing in a repository when initializing `struct progress`. Furthermore, store a pointer to the repository in that struct so that we can pass it to the trace2 API when logging information. Adjust callers accordingly by using `the_repository`. While there may be some callers that have a repository available in their context, this trivial conversion allows for easier verification and bubbles up the use of `the_repository` by one level. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

progress API: unify stop_progress{,_msg}(), fix trace2 bug

2022-02-03T23:39:59Z

Fix a bug that's been with us ever since 98a13647408 (trace2: log progress time and throughput, 2020-05-12), when the stop_progress_msg() API was used we didn't log a "region_leave" for the "region_enter" we start in "start_progress_delay()". The only user of the "stop_progress_msg()" function is "index-pack". Let's add a previously failing test to check that we have the same number of "region_enter" and "region_leave" events, with "-v" we'll log progress even in the test environment. In addition to that we've had a submarine bug here introduced with 9d81ecb52b5 (progress: add sparse mode to force 100% complete message, 2019-03-21). The "start_sparse_progress()" API would only do the right thing if the progress was ended with "stop_progress()", not "stop_progress_msg()". The only user of that API uses "stop_progress()", but let's still fix that along with the trace2 issue by making "stop_progress()" a trivial wrapper for "stop_progress_msg()". We can also drop the "if (progress)" test from "finish_if_sparse()". It's now a helper for the small "stop_progress_msg()" function. We'll already have returned from it if "progress" is "NULL". Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

progress.h: format and be consistent with progress.c naming

2022-02-03T23:39:55Z

Fix an inconsistency introduced in dc6a0757c4f (make struct progress an opaque type, 2007-10-30) and rename the "progress" parameters to stop_progress{,_msg}() to "p_progress". Now these match the corresponding parameters in the *.c code. While we're at it let's move the definition of the former below the latter, a subsequent change will start defining stop_progress() in terms of stop_progress_msg(). Let's also remove the excess whitespace at the end of the file. Signed-off-by: Ævar Arnfjörð Bjarmason 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

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: 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

progress: fix progress meters when dealing with lots of work

2017-11-15T04:11:25Z

The possibility of setting merge.renameLimit beyond 2^16 raises the possibility that the values passed to progress can exceed 2^32. Use uint64_t, because it "ought to be enough for anybody". :-) Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

progress: simplify "delayed" progress API

2017-08-19T21:01:34Z

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

nicer display of thin pack completion

2007-11-08T23:43:41Z

In the same spirit of prettifying Git's output display for mere mortals, here's a simple extension to the progress API allowing for a final message to be provided when terminating a progress line, and use it for the display of the number of objects needed to complete a thin pack, saving yet one more line of screen display. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano