Re: [PATCH] t3701-add-interactive: tighten the check of trace output

> Not that I'm totally opposed to your patch, but it's a little sad that
> we have to match the specific text used in GIT_TRACE now (and if they
> ever changed we won't even notice, but rather the test will just become
> a silent noop).
>
> I think it would be nice if we could move towards something like:
>
>   - move current GIT_TRACE messages to use GIT_TRACE_COMMAND or similar
>
>   - abolish trace_printf() without a specific subsystem key
>
>   - do one of:
>
>     - keep GIT_TRACE as a historical synonym for GIT_TRACE_COMMAND; that
>       keeps things working as they are now
>
>     - have GIT_TRACE enable _all_ tracing; that's a change in behavior,
>       but arguably a more useful thing to have going forward (e.g., when
>       you're not sure which traces are even available)
>
> And then a test like this would just use GIT_TRACE_COMMAND.

>
>> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
>> index 609fbfdc31..65dfbc033a 100755
>> --- a/t/t3701-add-interactive.sh
>> +++ b/t/t3701-add-interactive.sh
>> @@ -540,7 +540,7 @@ test_expect_success 'add -p does not expand argument lists' '
>>  	# update it, but we want to be sure that our "." pathspec
>>  	# was not expanded into the argument list of any command.
>>  	# So look only for "not-changed".
>> -	! grep not-changed trace.out
>> +	! grep -E "^trace: (built-in|exec|run_command): .*not-changed" trace.out
>
> I had a vague recollection that we preferred "egrep" to "grep -E" due to
> portability. But digging in the history, I could only find "fgrep" over
> "grep -F". And we seem to have plenty of "grep -E" invocations already.