Jeff King <peff@xxxxxxxx> writes:
> On Tue, Nov 03, 2020 at 10:34:09AM -0800, Junio C Hamano wrote:
>
>> > On our side, I don't think it would be _wrong_ to catch and disallow the
>> > combination. But it may be nicer to them if we continue to quietly
>> > ignore --follow and the pathspec in that case, for working with older
>> > versions. (OTOH, if I understand correctly they're segfaulting every
>> > time VS Code is used with v2.29 now, so they may have to accept it as an
>> > urgent fix anyway).
>>
>> So something like this won't harm VS Code more than we currently do,
>> while telling users what is wrong with their command line?
>
> Yeah, I was wondering if we'd want the patch you sent, or if we should
> turn those die() calls into warning() and disable the flags up front.
>
>> We may still want the "silently disable follow" at low-level
>> protection, but that does not give feedback why the end-user option
>> is silently ignored, so...
>
> I'd be just as happy to leave it out, if we think it isn't triggerable.
> The segfault would let people know we missed a spot. ;)
>
>> diff --git c/builtin/log.c w/builtin/log.c
>> index 9f939e6cdf..8811084f02 100644
>> --- c/builtin/log.c
>> +++ w/builtin/log.c
>> @@ -206,6 +206,13 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
>> if (argc > 1)
>> die(_("unrecognized argument: %s"), argv[1]);
>>
>> + if (rev->line_level_traverse) {
>> + if (rev->diffopt.filter)
>> + die(_("-L<range>:<file> cannot be used with pathspec"));
>
> Should this be checking rev->diffopt.pathspec.nr?
Embarrassing but yes ;-).
