Jeff King <peff@xxxxxxxx> writes:
> 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.
Yup. Sounds like a better world.
>
>> 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.
I had the same reaction and came to the same conclusion. FWIW, the
"favor fgrep over -F" was done by you with 87539416 ("tests: grep
portability fixes", 2008-09-30).
