Chris Down <chris@xxxxxxxxxxxxxx> writes:
> +__attribute__((format (printf, 1, 2)))
> +static void bisect_log_printf(const char *fmt, ...)
> +{
> + va_list ap;
> + char buf[1024];
> +
> + va_start(ap, fmt);
> + if (vsnprintf(buf, sizeof(buf), fmt, ap) < 0)
> + *buf = '\0';
> + va_end(ap);
We should just do
struct strbuf buf = STRBUF_INIT;
va_start(ap, fmt);
strbuf_vaddf(&buf, fmt, ap);
va_end(ap);
> + printf("%s", buf);
> + append_to_file(git_path_bisect_log(), "# %s", buf);
and free the resource with
strbuf_release(&buf);
I think.
> +}
> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> index a02587d1a7..d16730a2e2 100755
> --- a/t/t6030-bisect-porcelain.sh
> +++ b/t/t6030-bisect-porcelain.sh
> @@ -1029,18 +1029,23 @@ test_expect_success 'bisect state output with multiple good commits' '
> git bisect reset &&
> git bisect start >output &&
> grep "waiting for both good and bad commits" output &&
> + git bisect log | grep "waiting for both good and bad commits" &&
Having "git" command on the left hand side of pipe would hide a
failure signalled by its exit status from the command. The "but if
the command fails, how likely would we see the expected output to
its standard ouput?" argument aside, it is more common to write
git bisect log >output &&
grep "..." &&
instead.
Thanks.
