From: Drew Northup Date: Wed, 27 Apr 2011 19:11:11 GMT Subject: Re: [PATCH 01/23] Introduce git-test.sh and git-test-lib.sh Message-ID: <1303931471.25134.54.camel@drew-northup.unet.maine.edu> In-Reply-To: <1303543372-77843-2-git-send-email-jon.seymour@gmail.com> On Sat, 2011-04-23 at 17:22 +1000, Jon Seymour wrote: > This command is intended provide a uniform command line interface > to a suite of assertions that can be made about the state of > the working tree, index and repository. > > This commit introduces the core assert infrastructure. Subsequent > commits will introduce check functions that extend the infrastructure > in a modular way with additional tests. ..... > +'test_condition' [-- [ arg ... ]] ... > +'require_condition_libs' > + > + > +DESCRIPTION > +----------- > +`git test` provides a uniform, extensible API for evaluating various conditions that > +pertain to the state of a git working tree, index and repository. > + > +Specified conditions are evaluated from left to right. If any condition evaluates to false, > +the command conditionally prints a diagnostic message to stderr and sets a > +non-zero status code. Otherwise, sets a status code of zero. > + > +The message used to report a assertion failure may be overidden by specifying the --message option. > + > +Diagnostic output resulting from an assertion failure may be suppressed with the -q option. > +Note that the -q option does not suppress diagnostic output that results from the failure to > +successfully parse the arguments that configure the test API. ..... Is this supposed to be a porcelain or plumbing? The name could probably be better to avoid confusion with the "unit testing" code in t/. Additionally, I'd like to know why this shouldn't be implemented as some sort of 'git status --assert="XXXX"' call... -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59