Gatla Vishweshwar Reddy [off-list ref] writes:

Piping git commands directly to wc -l suppresses the exit code of
git, hiding potential failures from the test suite. Capture the
output to a temporary file first, then count the lines separately
to preserve the exit code. Where the expected count is known ahead
of time, use test_stdout_line_count instead.

Signed-off-by: Gatla Vishweshwar Reddy <redacted>
---
 t/t1410-reflog.sh | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

The above descripotion looks reasonble.

By the way, Documentation/SubmittingPatches has this:

    Before sending another version, make sure you have answered
    meaningful review comments in the existing discussion.  Also
    give reviewers enough time to comment before sending another
    version.

Now, you no longer have new consecutive blank lines in the above,
but the above shares the same "what did the author meant to convey
with this blank line?" puzzlement.

The updated code somehow wanders around in many directions like a
drunken man.  Let's comment on each line.

+	test_stdout_line_count = 5 git reflog &&

This is "Does the reflog for HEAD have exactly 5 entries?" test.

+	git reflog >reflog_output &&
+	HEAD_entry_count=$(wc -l <reflog_output) &&

As we already saw that HEAD_entry_count variable is exactly equal to
5, it is puzzling why we want to perform this computation again and
assign the result to the variable.

+	test_stdout_line_count = 5 git reflog show main &&

And then we check "Does the reflog for 'main' have exactly 5
entries?"

+	git reflog show main >reflog_main_output &&
+	main_entry_count=$(wc -l <reflog_main_output) &&

And recompute what we already know and asssign to main_entry_count
variable, which shares the same puzzlement.

 
 	git reflog delete main@{1} &&
 	git reflog show main > output &&
 	test_line_count = $(($main_entry_count - 1)) output &&

Now, after a blank line, it goes on to test a completely different
thing, which is "after deleting an entry in main's reflog, can we
count how many there is, and does it match what we expect, which is
the previous count minus 1"?  Why should we even need to do so, when

	git reflog delete main@{1} &&
	test_stdout_line_count = 4 git reflog show main &&

would do just fine?

-	test $HEAD_entry_count = $(git reflog | wc -l) &&
+	git reflog >reflog_output &&
+	test $HEAD_entry_count = $(wc -l <reflog_output) &&

And then it comes back to test what we already know, i.e. "does the
reflog for HEAD have 5 entries?".  Which we tested earlier already.

Are we interested in checking that "reflog delete main@{1}" does
not affect the reflog for HEAD?  If so, doing

	test_stdout_line_count = 5 git reflog &&

again here would be simpler, no?  That way, there is no need to
recompute and assign to the {HEAD,main}_entry_count variables in the
earlier part of the tests.

I guess the same comment applies to the remainder of this test,
where it is checked that a removal from HEAD reflog does not affect
the reflog of main.