Re: [PATCH] t/README: test_must_fail is for testing Git

2013-06-04 Thread Philip Oakley

From: "Junio C Hamano" 
Sent: Tuesday, June 04, 2013 9:49 PM

"Philip Oakley"  writes:


From: "Junio C Hamano" 
Sent: Tuesday, June 04, 2013 5:50 PM

When a test wants to make sure there is no  in an output
file, we should just say "! grep string output";


Small nit: It took me two readings of the commit message to correctly
parse this break point. The flowing together of the two parts with 
the

semicolon fooled me. Separate them?


 "test_must_fail"
is there only to test Git command and catch unusual deaths we know
about (e.g. segv) as an error, not as an expected failure.


Thanks.  Does this read better?


Yes.  Thanks.



   t/README: test_must_fail is for testing Git

   When a test wants to make sure there is no  in an output
   file, we should just say "! grep string output".

   "test_must_fail" is there only to test Git command and catch 
unusual

   deaths we know about (e.g. segv) as an error, not as an expected
   failure.  "test_must_fail grep string output" is unnecessary, as
   we are not making sure the system binaries do not dump core or
   anything like that.

   Signed-off-by: Junio C Hamano 
--


Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] t/README: test_must_fail is for testing Git

2013-06-04 Thread Junio C Hamano
"Philip Oakley"  writes:

> From: "Junio C Hamano" 
> Sent: Tuesday, June 04, 2013 5:50 PM
>> When a test wants to make sure there is no  in an output
>> file, we should just say "! grep string output";
>
> Small nit: It took me two readings of the commit message to correctly
> parse this break point. The flowing together of the two parts with the
> semicolon fooled me. Separate them?
>
>>  "test_must_fail"
>> is there only to test Git command and catch unusual deaths we know
>> about (e.g. segv) as an error, not as an expected failure.

Thanks.  Does this read better?

t/README: test_must_fail is for testing Git

When a test wants to make sure there is no  in an output
file, we should just say "! grep string output".

"test_must_fail" is there only to test Git command and catch unusual
deaths we know about (e.g. segv) as an error, not as an expected
failure.  "test_must_fail grep string output" is unnecessary, as
we are not making sure the system binaries do not dump core or
anything like that.

Signed-off-by: Junio C Hamano 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] t/README: test_must_fail is for testing Git

2013-06-04 Thread Philip Oakley

From: "Junio C Hamano" 
Sent: Tuesday, June 04, 2013 5:50 PM

When a test wants to make sure there is no  in an output
file, we should just say "! grep string output";


Small nit: It took me two readings of the commit message to correctly 
parse this break point. The flowing together of the two parts with the 
semicolon fooled me. Separate them?



 "test_must_fail"
is there only to test Git command and catch unusual deaths we know
about (e.g. segv) as an error, not as an expected failure.

Signed-off-by: Junio C Hamano 
---
t/README | 3 +++
1 file changed, 3 insertions(+)

diff --git a/t/README b/t/README
index e669bb3..35b3c5c 100644
--- a/t/README
+++ b/t/README
@@ -324,6 +324,9 @@ Don't:
   use 'test_must_fail git cmd'.  This will signal a failure if git
   dies in an unexpected way (e.g. segfault).

+   On the other hand, don't use test_must_fail for running regular
+   platform commands; just use '! cmd'.
+
 - use perl without spelling it as "$PERL_PATH". This is to help our
   friends on Windows where the platform Perl often adds CR before
   the end of line, and they bundle Git with a version of Perl that
--


Philip 


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html