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

Jeff King [off-list ref] 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.

quoted

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).