Re: [PATCH] diff: fix a segfault in >2 tree -I<regex> and --output=<file>

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 24, 2022, 20:17 UTC
Message-ID: <220524.86v8tuvfl1.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqqmtf6hgae.fsf@gitster.g>

On Tue, May 24 2022, Junio C Hamano wrote:

Show 12 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> I.e. the "right" thing to do in this case would require a much more
>> involved fix. We've somehow ended up not supporting --output=<file>, -I
>> and probably many other options in the combined-diff mode, which both in
>> testing and in this part of the implementation seems to have become an
>> afterthought.
>
> OK, a hopefully final question.
>
> How much less involved is it to add a new code (without doing
> anything in this patch)

...yeah, I think for this one it makes sense to narrowly focus on the segfault...

Show 7 quoted lines

> to detect and die on the combination of
> combined-diff with these two options, so that we can document the
> fact that we do not support them?  It would give us much better way
> forward than leaving the command silently ignore and give result
> that is not in line with what was asked, wouldn't it?  That way, the
> much more involved "fix" will turn into a change to add a missing
> feature.

I think not much, it's rather trivial for the case where we invoke "git diff", I.e. just adding something to the "builtin_diff_combined()" branch in builtin/diff.c to detect these two cases specifically.

I haven't looked in any depth into how we might reach code in combine-diff.c through other means, and if any of it can set these two indirectly somewhere else (i.e. other things that take diff options).

I also wonder if I'm just wrong in my assessment that it's a Bad Thing that we take some of these without ever doing anything with them in some modes, e.g.:

	git log --oneline -I foo

This will never do anything with that "-I foo" by definition, but would as soon as you add -p, should we error without -p (or other diff-showing options).

The same goes for range-diff, format-patch, --remerge-diff and any number of other things where we take the full set of options, but only do something with a limited subset of them.

It is helpful in some cases if we were more anal about it, e.g. when I was wondering why -I didn't do anything with the combined diff, but also handy for scripting and one-liners if you can tweak the command-line back & forth without it being so strict.

So I don't know. Maybe I'm just trying to talk myself out of pulling on that (bound to be long) thread, but I'm coming more around to this just being a non-issue beyond the narrow and needed fix for diff_free() in particular.

I.e. the more general approach of chasing down options that don't do anything for a given "diff mode". We might still want to error on some particular ones, such as -I with the combined diff (but not with --oneline, or whatever).