Re: [PATCHv2] add: ignore only ignored files

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Sun, Nov 23, 2014 at 10:10:47AM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > ... Possibly because I do not know that those instructions
>> > are written down anywhere. We usually catch such things in review these
>> > days, but there are many inconsistent spots in the existing suite.
>> 
>> t/README has this
>> 
>>     Don't:
>> 
>>      - use '! git cmd' when you want to make sure the git command exits
>>        with failure in a controlled way by calling "die()".  Instead,
>>        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'.
>
> Thanks, I did not actually look and relied on my memory, which was
> obviously wrong. I agree that the instructions there are sufficient.
>
>> Do we refer to t/README from CodingGuidelines where we tell the
>> developers to always write tests to prevent other people from
>> breaking tomorrow what you did today?  If not, perhaps that is what
>> needs to be added.
>
> That might make sense. It might also be that Torsten simply overlooked
> it when asking his question (i.e., there is nothing to fix,
> documentation is not always read completely, and we can move on).

We actually do not have a reference to it anywhere.  For now, this
should suffice.

 Documentation/SubmittingPatches | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index fa71b5f..a3861a6 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -57,7 +57,8 @@ change, the approach taken by the change, and if relevant how this
 differs substantially from the prior version, are all good things
 to have.
 
-Make sure that you have tests for the bug you are fixing.
+Make sure that you have tests for the bug you are fixing.  See
+t/README for guidance of writing tests.
 
 When adding a new feature, make sure that you have new tests to show
 the feature triggers the new behaviour when it should, and to show the