t5551: fix the 50,000 tag test

The first version of test 23 did simply check that no output was send to stderr.

Commit 5e2c7cd2 verified that the expected tags were actually cloned.

Since the day "git clone" printed "Cloning into 'too-many-refs'" to stderr, the test failed because stderr was not empty.

Remove the check for stderr and make t5551-23 pass again

---
 t/t5551-http-fetch-smart.sh | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

index e07eaf3..2c49133 100755
@@ -240,8 +240,7 @@ test_expect_success EXPENSIVE 'create 50,000 tags in the repo' '
 '
 
 test_expect_success EXPENSIVE 'clone the 50,000 tag repo to check OS command line overflow' '
-	git clone $HTTPD_URL/smart/repo.git too-many-refs 2>err &&
-	test_line_count = 0 err &&
+	git clone $HTTPD_URL/smart/repo.git too-many-refs &&
 	(
 		cd too-many-refs &&
 		test $(git for-each-ref refs/tags | wc -l) = 50000

2.0.0.553.ged01b91

Thanks. It is 68b939b2 (clone: send diagnostic messages to stderr, 2013-09-18); before it we showed the message to the standard output stream instead.

Will queue.

Thanks for digging, as we now know better:
do you want to squeeze in someting like this:

s/Since the day/Since commit 5e2c7cd2/

I usually do not dig only to give suggestions to others, which will risk the time I spent to go to total waste. When I find the log message lacking, and if the patch looked otherwise OK enough, I do the digging myself in order to tweak to reduce one round-trip (otherwise I'd just discard and tell the submitter to do the digging). I may send out what I learned as a response, but that is a mere "side effect"; the primary effect of queuing an improved patch has often already happened when you see the result of my digging.

I do not recall what I did for this particular patch, but you should be able to fetch and run "git log origin/master..origin/pu" to find out what I did ;-).

Thanks.