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' [--<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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html