From: "René Scharfe" <l.s.r@web.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 4/7] commit-graph: fix bogus counter in "Scanning merged commits" progress line
Date: Sun, 4 Jul 2021 14:15:34 +0200 [thread overview]
Message-ID: <ca3eba46-7c83-51fd-2d65-c55309ac7182@web.de> (raw)
In-Reply-To: <874kdkxot4.fsf@evledraar.gmail.com>
Am 26.06.21 um 23:38 schrieb Ævar Arnfjörð Bjarmason:
>
> On Sat, Jun 26 2021, René Scharfe wrote:
>
>> Am 26.06.21 um 16:11 schrieb Ævar Arnfjörð Bjarmason:
>>> [...]
>>> To reference my earlier E-Mail[1] are you eating the first apple or the
>>> zeroeth apple? I don't think one is more or less right in the
>>> mathematical sense, I just think for UX aimed at people counting "laps"
>>> makes more sense than counting completed items.
>>
>> The difference between counting iterations and work items vanishes as
>> their numbers increase. The most pronounced difference is observed when
>> there is only a single item of work. The count-iterations model shows
>> 1/1 from start to finish. The count-work model shows 0/1 initially and
>> 1/1 after the work is done.
>>
>> As a user I prefer the second one. If presented with just a number and
>> a percentage then I assume 100% means all work is done and would cancel
>> the program if that status is shown for too long. With Git I have
>> learned that only the final ", done" really means done in some cases,
>> but that's an unnecessary lesson and still surprising to me.
>
> What progress bar of ours goes slow enough that the difference matters
> for you in either case?
I don't have an example -- Git, network and SSD are quick enough for my
small use cases.
The advantage of the count-work method is that the question doesn't even
come up.
> The only one I know of is "Enumerating objects", which notably stalls at
> the start, and which I'm proposing changing the output of in:
> https://lore.kernel.org/git/patch-18.25-e21fc66623f-20210623T155626Z-avarab@gmail.com/
That's annoying, but the first number I see there has five or six digits,
so it's not an example of the issue mentioned above for me.
Your patch shows ", stalled." while pack-objects starts up. I'm not sure
this helps. Perhaps there are cases when it gets stuck, but it's hard to
determine by the clock alone. When I run gc, it just needs a few seconds
to prepare something and then starts visibly counting objects. A more
fine-grained report of the preparation steps would help, but seeing
"stalled" would just scare me.
>> The count-work model needs one more progress update than the
>> count-iteration model. We could do all updates in the loop header,
>> which is evaluated just the right number of times. But I think that we
>> rather should choose between the models based on their results.
>
> I think we should be more biased towards API convenience here than
> anything else, because for most of these they'll go so fast that users
> won't see the difference. I just also happen to think that the easy way
> to do it is also more correct.
The convenience of having one less display_progress() call is only a
slight advantage.
Correctness is a matter of definitions. Recently I learned that in Arabic
a person's age is given using the count-iterations model. I.e. on the day
of your birth your age is one. That causes trouble if you deal with
state officials that use the count-work, err, count-completed-years model,
where your age is one only after living through a full year.
The solution around here is to avoid ambiguity by not using terms like
"age" in laws, regulations and forms, but to state explicitly "full years
since birth" or so.
"2/3 (33%)" means something else to me than to you by default. So a
solution could be to state the model explicitly. I.e. "2/3 (66%) done"
or "working on 2/3 (66%)", but the percentage doesn't quite fit in the
latter case. Thoughts?
> Also, because for these cases that you're focusing on where we count up
> to exactly 100% and we therefore expect N calls to display_progress()
> (igroning the rare but allowed duplicate calls with the same number,
> which most callers don't use). We could just have a convenience API of:
>
> start_progress()
> for i in (0..X-1):
> progress_update() /* passing "i" not needed, we increment internally */
> work()
> stop_progress()
>
> Then we could even make showing 0/N or 1/N the first time configuable,
> but we could only do both if we use the API as I'm suggesting, not as
> you want to use it.
A function that increments the progress number relatively can be used
with both models. It's more useful for the count-iterations model,
though, as in the count-work model you can piggy-back on the loop
counter check:
for (i = 0; display_progress(p, i), i < X; i++)
work();
> You also sort of can get me what I want with with what you're
> suggesting, but you'd conflate "setup" work with the first item, which
> matters e.g. for "Enumerating objects" and my "stalled" patch. It's also
> more verbose at the code level, and complex (need to deal with "break",
> "continue"), so why would you?
It's not complicated, just slightly odd, because function calls are
seldomly put into the loop counter check.
>> If each work item finishes within a progress display update period
>> (half a second) then there won't be any user-visible difference and
>> both models would do.
>
> A trivial point, but don't you mean a second? AFAICT for "delayed" we
> display after 2 seconds, then update every 1 seconds, it's only if we
> have display_throughput() that we do every 0.5s.
Right, I mixed those up.
>>> The other is that if you count laps you can have your progress bar
>>> optionally show progress on that item. E.g. we could if we stall show
>>> seconds spend that we're hung on that item, or '3/3 ETA 40s". I have a
>>> patch[3] that takes an initial step towards that, with some more queued
>>> locally.
>>
>> A time estimate for the whole operation (until ", done") would be nice.
>> It can help with the decision to go for a break or to keep staring at
>> the screen. I guess we just need to remember when start_progress() was
>> called and can then estimate the remaining time once the first item is
>> done. Stalling items would push the estimate further into the future.
>>
>> A time estimate per item wouldn't help me much. I'd have to subtract
>> to get the number of unfinished items, catch the maximum estimated
>> duration and multiply those values. OK, by the time I manage that Git
>> is probably done -- but I'd rather like to leave arithmetic tasks to
>> the computer..
>>
>> Seconds spent for the current item can be shown with both models. The
>> progress value is not sufficient to identify the problem case in most
>> cases. An ID of some kind (e.g. a file name or hash) would have to be
>> shown as well for that. But how would I use that information?
>
> If we're spending enough time on one item to update progress for it N
> times we probably want to show throughput/progress/ETA mainly for that
> item, not the work as a whole.
Throughput is shown for the last time period. It is independent of the
item or items being worked on during that period. If one item takes
multiple periods to finish then indeed only its current progress is
shown automatically, as you want.
Showing intra-item progress requires some kind of hierarchical API to
keep track of both parent and child progress and show them in some
readable way. Perhaps appending another progress display would suffice?
"Files 1/3 (33%) Bytes 17kB/9GB (0%)". Not sure.
Calculating the ETA of a single item seems hard. It does require intra-
item progress to be reported by the work code.
> If we do run into those cases and want to convert them to show some
> intra-item progress we'd need to first migrate them over to suggested
> way of using the API if we picked yours first, with my suggested use we
> only need to add new API calls (display_throughput(), and similar future
> calls/implicit display).
I don't see why. The intra-item progress numbers need to be reported in
any case if they are to be shown somehow. If the model is clear then we
can show unambiguous output.
> Consider e.g. using the packfile-uri response to ask the user to
> download N number of URLs, just because we grab one at 1MB/s that
> probably won't do much to inform our estimate of the next one (which may
> be on a different CDN etc.).
Sure, if the speed of work items varies wildly then estimates will be
unreliable.
I can vaguely imagine that it would be kind of useful to know the
throughput of different data sources, to allow e.g. use a different
mirror next time. The current API doesn't distinguish work items in a
meaningful way, though. They only have numbers. I'd need a name (e.g.
the URL) for intra-item progress numbers to mean something.
René
next prev parent reply other threads:[~2021-07-04 12:15 UTC|newest]
Thread overview: 197+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-20 20:02 [PATCH 0/7] progress: verify progress counters in the test suite SZEDER Gábor
2021-06-20 20:02 ` [PATCH 1/7] progress: introduce GIT_TEST_CHECK_PROGRESS to verify progress counters SZEDER Gábor
2021-06-21 7:09 ` Ævar Arnfjörð Bjarmason
2021-06-22 15:55 ` Taylor Blau
2021-06-20 20:02 ` [PATCH 2/7] progress: catch nested/overlapping progresses with GIT_TEST_CHECK_PROGRESS SZEDER Gábor
2021-06-22 16:00 ` Taylor Blau
2021-08-30 21:15 ` SZEDER Gábor
2021-06-20 20:02 ` [PATCH 3/7] progress: catch backwards counting " SZEDER Gábor
2021-06-20 20:03 ` [PATCH 4/7] commit-graph: fix bogus counter in "Scanning merged commits" progress line SZEDER Gábor
2021-06-20 22:13 ` Ævar Arnfjörð Bjarmason
2021-06-21 18:32 ` René Scharfe
2021-06-21 20:08 ` Ævar Arnfjörð Bjarmason
2021-06-26 8:27 ` René Scharfe
2021-06-26 14:11 ` Ævar Arnfjörð Bjarmason
2021-06-26 20:22 ` René Scharfe
2021-06-26 21:38 ` Ævar Arnfjörð Bjarmason
2021-07-04 12:15 ` René Scharfe [this message]
2021-07-05 14:09 ` Junio C Hamano
2021-07-05 23:28 ` Ævar Arnfjörð Bjarmason
2021-07-06 16:02 ` René Scharfe
2021-06-27 17:31 ` Felipe Contreras
2021-06-20 20:03 ` [PATCH 5/7] entry: show finer-grained counter in "Filtering content" " SZEDER Gábor
2021-06-20 20:03 ` [PATCH 6/7] [RFC] entry: don't show "Filtering content: ... done." line in case of errors SZEDER Gábor
2021-06-21 18:32 ` René Scharfe
2021-06-23 1:52 ` Taylor Blau
2021-08-30 21:17 ` SZEDER Gábor
2021-06-20 20:03 ` [PATCH 7/7] test-lib: enable GIT_TEST_CHECK_PROGRESS by default SZEDER Gábor
2021-06-21 0:59 ` [PATCH 0/7] progress: verify progress counters in the test suite Ævar Arnfjörð Bjarmason
2021-06-23 2:04 ` Taylor Blau
2021-06-23 17:48 ` [PATCH 00/25] progress.c: various fixes + SZEDER's RFC code Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 01/25] progress.c tests: fix breakage with COLUMNS != 80 Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 02/25] progress.c tests: make start/stop verbs on stdin Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 03/25] progress.c tests: test some invalid usage Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 04/25] progress.c tests: add a "signal" verb Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 05/25] progress.c: move signal handler functions lower Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 06/25] progress.c: call progress_interval() from progress_test_force_update() Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 07/25] progress.c: stop eagerly fflush(stderr) when not a terminal Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 08/25] progress.c: add temporary variable from progress struct Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 09/25] midx perf: add a perf test for multi-pack-index Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 10/25] progress.c: remove the "sparse" mode nano-optimization Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 11/25] pack-bitmap-write.c: add a missing stop_progress() Ævar Arnfjörð Bjarmason
2021-09-17 5:14 ` SZEDER Gábor
2021-09-17 5:56 ` Ævar Arnfjörð Bjarmason
2021-09-17 21:38 ` SZEDER Gábor
2021-06-23 17:48 ` [PATCH 12/25] progress.c: add & assert a "global_progress" variable Ævar Arnfjörð Bjarmason
2021-09-16 18:31 ` SZEDER Gábor
2021-06-23 17:48 ` [PATCH 13/25] progress.[ch]: move the "struct progress" to the header Ævar Arnfjörð Bjarmason
2021-09-16 19:42 ` SZEDER Gábor
2021-06-23 17:48 ` [PATCH 14/25] progress.[ch]: move test-only code away from "extern" variables Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 15/25] progress.c: pass "is done?" (again) to display() Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 16/25] progress.[ch]: convert "title" to "struct strbuf" Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 17/25] progress.c: refactor display() for less confusion, and fix bug Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 18/25] progress.c: emit progress on first signal, show "stalled" Ævar Arnfjörð Bjarmason
2021-09-16 18:37 ` SZEDER Gábor
2021-06-23 17:48 ` [PATCH 19/25] commit-graph: fix bogus counter in "Scanning merged commits" progress line Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 20/25] midx: don't provide a total for QSORT() progress Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 21/25] entry: show finer-grained counter in "Filtering content" progress line Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [PATCH 22/25] progress.c: add a stop_progress_early() function Ævar Arnfjörð Bjarmason
2021-06-24 10:35 ` Ævar Arnfjörð Bjarmason
2021-06-25 1:24 ` Andrei Rybak
2021-06-23 17:48 ` [PATCH 23/25] entry: deal with unexpected "Filtering content" total Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [RFC/PATCH 24/25] progress: assert last update in stop_progress() Ævar Arnfjörð Bjarmason
2021-06-23 17:48 ` [RFC/PATCH 25/25] progress: assert counting upwards in display() Ævar Arnfjörð Bjarmason
2021-06-23 17:59 ` [PATCH 00/25] progress.c: various fixes + SZEDER's RFC code Randall S. Becker
2021-06-23 20:01 ` Ævar Arnfjörð Bjarmason
2021-06-23 20:25 ` Randall S. Becker
2021-06-23 21:57 ` [PATCH 0/4] WIP/POC check isatty(2)-protected progress lines SZEDER Gábor
2021-06-23 21:57 ` [PATCH 1/4] WIP progress, isatty(2), hidden progress lnies for GIT_TEST_CHECK_PROGRESS SZEDER Gábor
2021-06-23 21:57 ` [PATCH 2/4] blame: fix progress total with line ranges SZEDER Gábor
2021-06-23 21:57 ` [PATCH 3/4] read-cache: avoid overlapping progress lines SZEDER Gábor
2021-06-23 21:57 ` [PATCH 4/4] preload-index: fix "Refreshing index" progress line SZEDER Gábor
2021-06-23 22:11 ` [PATCH 0/4] WIP/POC check isatty(2)-protected progress lines SZEDER Gábor
2021-06-24 10:43 ` Ævar Arnfjörð Bjarmason
2021-06-24 10:45 ` Ævar Arnfjörð Bjarmason
2021-07-22 12:20 ` [PATCH 0/3] progress.c API users: fix bogus counting Ævar Arnfjörð Bjarmason
2021-07-22 12:20 ` [PATCH 1/3] commit-graph: fix bogus counter in "Scanning merged commits" progress line Ævar Arnfjörð Bjarmason
2021-07-23 21:55 ` Junio C Hamano
2021-08-02 21:07 ` SZEDER Gábor
2021-07-22 12:20 ` [PATCH 2/3] midx: don't provide a total for QSORT() progress Ævar Arnfjörð Bjarmason
2021-07-23 21:56 ` Junio C Hamano
2021-08-05 15:07 ` Phillip Wood
2021-08-05 19:07 ` Ævar Arnfjörð Bjarmason
2021-07-22 12:20 ` [PATCH 3/3] entry: show finer-grained counter in "Filtering content" progress line Ævar Arnfjörð Bjarmason
2021-07-23 22:01 ` Junio C Hamano
2021-08-02 22:05 ` SZEDER Gábor
2021-08-02 21:48 ` SZEDER Gábor
2021-08-05 11:01 ` [PATCH v2 0/3] progress.c API users: fix bogus counting Ævar Arnfjörð Bjarmason
2021-08-05 11:01 ` [PATCH v2 1/3] commit-graph: fix bogus counter in "Scanning merged commits" progress line Ævar Arnfjörð Bjarmason
2021-08-05 11:01 ` [PATCH v2 2/3] midx: don't provide a total for QSORT() progress Ævar Arnfjörð Bjarmason
2021-08-05 11:01 ` [PATCH v2 3/3] entry: show finer-grained counter in "Filtering content" progress line Ævar Arnfjörð Bjarmason
2021-08-23 10:29 ` [PATCH v3 0/2] progress.c API users: fix bogus counting Ævar Arnfjörð Bjarmason
2021-08-23 10:29 ` [PATCH v3 1/2] commit-graph: fix bogus counter in "Scanning merged commits" progress line Ævar Arnfjörð Bjarmason
2021-08-23 10:29 ` [PATCH v3 2/2] entry: show finer-grained counter in "Filtering content" " Ævar Arnfjörð Bjarmason
2021-09-09 1:10 ` [PATCH v4 0/2] progress.c API users: fix bogus counting Ævar Arnfjörð Bjarmason
2021-09-09 1:10 ` [PATCH v4 1/2] commit-graph: fix bogus counter in "Scanning merged commits" progress line Ævar Arnfjörð Bjarmason
2021-09-09 1:10 ` [PATCH v4 2/2] entry: show finer-grained counter in "Filtering content" " Ævar Arnfjörð Bjarmason
2021-09-09 20:02 ` [PATCH v4 0/2] progress.c API users: fix bogus counting Junio C Hamano
2021-07-22 12:54 ` [PATCH 0/8] progress: assert "global_progress" + test fixes / cleanup Ævar Arnfjörð Bjarmason
2021-07-22 12:54 ` [PATCH 1/8] progress.c tests: make start/stop verbs on stdin Ævar Arnfjörð Bjarmason
2021-07-22 12:55 ` [PATCH 2/8] progress.c tests: test some invalid usage Ævar Arnfjörð Bjarmason
2021-07-22 12:55 ` [PATCH 3/8] progress.c: move signal handler functions lower Ævar Arnfjörð Bjarmason
2021-07-22 12:55 ` [PATCH 4/8] progress.c: call progress_interval() from progress_test_force_update() Ævar Arnfjörð Bjarmason
2021-07-22 12:55 ` [PATCH 5/8] progress.c: stop eagerly fflush(stderr) when not a terminal Ævar Arnfjörð Bjarmason
2021-07-22 12:55 ` [PATCH 6/8] progress.c: add temporary variable from progress struct Ævar Arnfjörð Bjarmason
2021-07-22 12:55 ` [PATCH 7/8] pack-bitmap-write.c: add a missing stop_progress() Ævar Arnfjörð Bjarmason
2021-07-22 12:55 ` [PATCH 8/8] progress.c: add & assert a "global_progress" variable Ævar Arnfjörð Bjarmason
2021-09-16 21:34 ` [PATCH 12/25] " Ævar Arnfjörð Bjarmason
2021-07-23 22:02 ` [PATCH 0/8] progress: assert "global_progress" + test fixes / cleanup Junio C Hamano
2021-09-20 23:09 ` [PATCH v2 " Ævar Arnfjörð Bjarmason
2021-09-20 23:09 ` [PATCH v2 1/8] progress.c tests: make start/stop verbs on stdin Ævar Arnfjörð Bjarmason
2021-10-08 3:43 ` Emily Shaffer
2021-09-20 23:09 ` [PATCH v2 2/8] progress.c tests: test some invalid usage Ævar Arnfjörð Bjarmason
2021-10-08 3:53 ` Emily Shaffer
2021-09-20 23:09 ` [PATCH v2 3/8] progress.c: move signal handler functions lower Ævar Arnfjörð Bjarmason
2021-09-20 23:09 ` [PATCH v2 4/8] progress.c: call progress_interval() from progress_test_force_update() Ævar Arnfjörð Bjarmason
2021-09-20 23:09 ` [PATCH v2 5/8] progress.c: stop eagerly fflush(stderr) when not a terminal Ævar Arnfjörð Bjarmason
2021-10-08 3:59 ` Emily Shaffer
2021-10-08 7:01 ` Ævar Arnfjörð Bjarmason
2021-09-20 23:09 ` [PATCH v2 6/8] progress.c: add temporary variable from progress struct Ævar Arnfjörð Bjarmason
2021-10-08 4:02 ` Emily Shaffer
2021-09-20 23:09 ` [PATCH v2 7/8] pack-bitmap-write.c: add a missing stop_progress() Ævar Arnfjörð Bjarmason
2021-10-08 4:04 ` Emily Shaffer
2021-10-08 12:14 ` Ævar Arnfjörð Bjarmason
2021-10-10 21:29 ` SZEDER Gábor
2021-09-20 23:09 ` [PATCH v2 8/8] progress.c: add & assert a "global_progress" variable Ævar Arnfjörð Bjarmason
2021-10-08 4:18 ` Emily Shaffer
2021-10-08 7:15 ` Ævar Arnfjörð Bjarmason
2021-10-13 22:28 ` [PATCH v3 00/10] progress: assert "global_progress" + test fixes / cleanup Ævar Arnfjörð Bjarmason
2021-10-13 22:28 ` [PATCH v3 01/10] leak tests: fix a memory leaks in "test-progress" helper Ævar Arnfjörð Bjarmason
2021-10-13 22:28 ` [PATCH v3 02/10] progress.c test helper: add missing braces Ævar Arnfjörð Bjarmason
2021-10-13 22:28 ` [PATCH v3 03/10] progress.c tests: make start/stop verbs on stdin Ævar Arnfjörð Bjarmason
2021-10-21 22:30 ` SZEDER Gábor
2021-10-22 14:18 ` Ævar Arnfjörð Bjarmason
2021-10-22 22:14 ` Taylor Blau
2021-10-24 20:10 ` SZEDER Gábor
2021-10-22 3:34 ` Emily Shaffer
2021-10-13 22:28 ` [PATCH v3 04/10] progress.c tests: test some invalid usage Ævar Arnfjörð Bjarmason
2021-10-13 22:28 ` [PATCH v3 05/10] progress.c: move signal handler functions lower Ævar Arnfjörð Bjarmason
2021-10-13 22:28 ` [PATCH v3 06/10] progress.c: call progress_interval() from progress_test_force_update() Ævar Arnfjörð Bjarmason
2021-10-22 22:28 ` Taylor Blau
2021-10-13 22:28 ` [PATCH v3 07/10] progress.c: add temporary variable from progress struct Ævar Arnfjörð Bjarmason
2021-10-22 22:37 ` Taylor Blau
2021-10-13 22:28 ` [PATCH v3 08/10] pack-bitmap-write.c: don't return without stop_progress() Ævar Arnfjörð Bjarmason
2021-10-22 3:37 ` Emily Shaffer
2021-10-22 22:47 ` Taylor Blau
2021-10-13 22:28 ` [PATCH v3 09/10] various *.c: use isatty(1|2), not isatty(STDIN_FILENO|STDERR_FILENO) Ævar Arnfjörð Bjarmason
2021-10-22 3:39 ` Emily Shaffer
2021-10-13 22:28 ` [PATCH v3 10/10] progress.c: add & assert a "global_progress" variable Ævar Arnfjörð Bjarmason
2021-10-22 3:42 ` Emily Shaffer
2021-10-25 5:02 ` SZEDER Gábor
2021-10-25 9:38 ` Junio C Hamano
2021-12-02 23:14 ` SZEDER Gábor
2021-12-03 10:29 ` Ævar Arnfjörð Bjarmason
2021-10-25 11:06 ` Ævar Arnfjörð Bjarmason
2021-10-22 3:44 ` [PATCH v3 00/10] progress: assert "global_progress" + test fixes / cleanup Emily Shaffer
2021-10-22 14:21 ` Ævar Arnfjörð Bjarmason
2021-10-25 11:24 ` [PATCH v4 0/8] " Ævar Arnfjörð Bjarmason
2021-10-25 11:25 ` [PATCH v4 1/8] leak tests: fix a memory leaks in "test-progress" helper Ævar Arnfjörð Bjarmason
2021-10-25 11:25 ` [PATCH v4 2/8] progress.c test helper: add missing braces Ævar Arnfjörð Bjarmason
2021-10-25 11:25 ` [PATCH v4 3/8] progress.c tests: make start/stop commands on stdin Ævar Arnfjörð Bjarmason
2021-10-25 11:25 ` [PATCH v4 4/8] progress.c tests: test some invalid usage Ævar Arnfjörð Bjarmason
2021-10-25 11:25 ` [PATCH v4 5/8] progress.c: add temporary variable from progress struct Ævar Arnfjörð Bjarmason
2021-10-25 11:25 ` [PATCH v4 6/8] pack-bitmap-write.c: don't return without stop_progress() Ævar Arnfjörð Bjarmason
2021-10-25 11:25 ` [PATCH v4 7/8] various *.c: use isatty(1|2), not isatty(STDIN_FILENO|STDERR_FILENO) Ævar Arnfjörð Bjarmason
2021-10-25 11:25 ` [PATCH v4 8/8] progress.c: add & assert a "global_progress" variable Ævar Arnfjörð Bjarmason
2021-10-25 11:53 ` Johannes Sixt
2021-10-25 12:29 ` Ævar Arnfjörð Bjarmason
2021-11-01 19:09 ` [PATCH v5 0/8] progress: assert "global_progress" + test fixes / cleanup Ævar Arnfjörð Bjarmason
2021-11-01 19:09 ` [PATCH v5 1/8] leak tests: fix a memory leaks in "test-progress" helper Ævar Arnfjörð Bjarmason
2021-11-01 19:09 ` [PATCH v5 2/8] progress.c test helper: add missing braces Ævar Arnfjörð Bjarmason
2021-11-01 19:09 ` [PATCH v5 3/8] progress.c tests: make start/stop commands on stdin Ævar Arnfjörð Bjarmason
2021-11-01 19:09 ` [PATCH v5 4/8] progress.c tests: test some invalid usage Ævar Arnfjörð Bjarmason
2021-11-01 19:09 ` [PATCH v5 5/8] progress.c: add temporary variable from progress struct Ævar Arnfjörð Bjarmason
2021-11-01 19:09 ` [PATCH v5 6/8] pack-bitmap-write.c: don't return without stop_progress() Ævar Arnfjörð Bjarmason
2021-11-01 19:09 ` [PATCH v5 7/8] various *.c: use isatty(1|2), not isatty(STDIN_FILENO|STDERR_FILENO) Ævar Arnfjörð Bjarmason
2021-11-02 0:58 ` Carlo Arenas
2021-11-01 19:09 ` [PATCH v5 8/8] progress.c: add & assert a "global_progress" variable Ævar Arnfjörð Bjarmason
2021-11-02 12:27 ` [PATCH v6 0/8] progress: assert "global_progress" + test fixes / cleanup Ævar Arnfjörð Bjarmason
2021-11-02 12:27 ` [PATCH v6 1/8] leak tests: fix a memory leaks in "test-progress" helper Ævar Arnfjörð Bjarmason
2021-11-02 12:27 ` [PATCH v6 2/8] progress.c test helper: add missing braces Ævar Arnfjörð Bjarmason
2021-11-02 12:27 ` [PATCH v6 3/8] progress.c tests: make start/stop commands on stdin Ævar Arnfjörð Bjarmason
2021-11-02 12:27 ` [PATCH v6 4/8] progress.c tests: test some invalid usage Ævar Arnfjörð Bjarmason
2021-11-02 12:27 ` [PATCH v6 5/8] progress.c: add temporary variable from progress struct Ævar Arnfjörð Bjarmason
2021-11-02 12:27 ` [PATCH v6 6/8] pack-bitmap-write.c: don't return without stop_progress() Ævar Arnfjörð Bjarmason
2021-11-02 12:27 ` [PATCH v6 7/8] various *.c: use isatty(0|2), not isatty(STDIN_FILENO|STDERR_FILENO) Ævar Arnfjörð Bjarmason
2021-11-02 12:27 ` [PATCH v6 8/8] progress.c: add & assert a "global_progress" variable Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 0/9] progress: test fixes / cleanup Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 1/9] leak tests: fix a memory leak in "test-progress" helper Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 2/9] progress.c test helper: add missing braces Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 3/9] progress.c tests: make start/stop commands on stdin Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 4/9] progress.c tests: test some invalid usage Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 5/9] progress.h: format and be consistent with progress.c naming Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 6/9] progress.c: use dereferenced "progress" variable, not "(*p_progress)" Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 7/9] progress.c: refactor stop_progress{,_msg}() to use helpers Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 8/9] progress API: unify stop_progress{,_msg}(), fix trace2 bug Ævar Arnfjörð Bjarmason
2022-02-03 21:40 ` [PATCH v9 9/9] pack-bitmap-write.c: don't return without stop_progress() Ævar Arnfjörð Bjarmason
2022-02-03 23:39 ` [PATCH v9 0/9] progress: test fixes / cleanup Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca3eba46-7c83-51fd-2d65-c55309ac7182@web.de \
--to=l.s.r@web.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).