Re: [PATCH 01/23] Introduce git-test.sh and git-test-lib.sh
- From
Drew Northup <drew.northup@maine.edu>
- Date
- Apr 27, 2011, 19:11 UTC
- 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:
Show 7 quoted lines
> 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.
.....
Show 18 quoted lines
> +'test_condition' [--<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