Re: [PATCHv2] add: ignore only ignored files
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 24, 2014, 17:41 UTC
- Message-ID
- <xmqqzjbgwl77.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20141123194624.GB16605@peff.net>
Jeff King <peff@peff.net> writes:
Show 31 quoted lines
> 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