Re: [PATCH] bisect: always call setup_revisions after init_revisions

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 17, 2016, 00:03 UTC
Message-ID: <xmqqoa703cly.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160616233719.GB15013@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> The former initializes the rev_info struct to default
> values, and the latter parsers any command-line arguments
> and finalizes the struct.

The former refers to init and the latter setup?

Show 16 quoted lines

> In e22278c (bisect: display first bad commit without forking
> a new process, 2009-05-28), a show_diff_tree() was added
> that calls the former but not the latter. It doesn't have
> any arguments to parse, but it still should do the
> finalizing step.
>
> This may have caused other minor bugs over the years, but it
> became much more prominent after fe37a9c (pretty: allow
> tweaking tabwidth in --expand-tabs, 2016-03-29). That leaves
> the expected tab width as "-1", rather than the true default
> of "8". When we see a commit with tabs to be expanded, we
> end up trying to add (size_t)-1 spaces to a strbuf, which
> complains about the integer overflow.
>
> The fix is easy: just call setup_revisions() with no
> arguments.

Thanks.

I wonder if we can make it even harder to make the same mistake again somehow. I notice that run_diff_files() and run_diff_index() in diff-lib.c share the ideal name for such an easy-to-use helper and run_diff_tree(), which does not exist yet, could sit alongside with them, but the actual implementation of the former two do not address this issue either. I guess that the diversity of the set of pre-packaged options that various callers want to use are so graet that we need a rather unpleasntly large API refactoring before we could even contemplate doing so?

In any case, this is a strict improvement. Let's queue it for the first maintenance release.

Show 22 quoted lines

> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Same patch as earlier, now with 100% more commit message.
>
> I didn't add a test, as it seemed weirdly specific to be checking "can
> bisect show a commit with tabs in it". I.e., it's not likely to actually
> regress in this specific way again.
>
>  bisect.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/bisect.c b/bisect.c
> index 6d93edb..dc13319 100644
> --- a/bisect.c
> +++ b/bisect.c
> @@ -890,6 +890,7 @@ static void show_diff_tree(const char *prefix, struct commit *commit)
>  	if (!opt.diffopt.output_format)
>  		opt.diffopt.output_format = DIFF_FORMAT_RAW;
>  
> +	setup_revisions(0, NULL, &opt, NULL);
>  	log_tree_commit(&opt, commit);
>  }