Arbit - project tracking, tracked with Arbit

With one additional condition not mentioned in the grammar, that no line should ever exceed 79 characters per line. A textual description of the rules above:

All messages should wrap at 79 characters per line. This means, if you are
writing multiple lines after a message starting with a "- " each following
line should be indented by exactly two spaces.
Including descriptive text in your commit messages is generally important to
offer a good overview on the commit when the issue tracker is not available
(commit mails, history).
All messages may include references to existing issues to add status updates
to the issue, which should look like::
- Refs #<number>: <text>
Where <number> references the ticket and the <text> describes what you did.
Comments
--------
You may always append arbitrary comments in your commit messages, where each
line should start with a number sign (#). Text in these lines won't be
checked.
Bug fix
-------
A bug fix commit message should follow the following scheme::
- Fixed #<number>: <text>
Where <number> references the closed bug and <text> is a description of the
bug and the fix. Keep in mind that the texts will be used for the changelog,
so please check the spelling before committing.
The bug number is not optional, which means that there should be an open bug
in the issue tracker for *each* bug you fix.
For compatibility with other issue tracker you may also use "Closed" instead
of "Fixed" in your message, but "Fixed" is highly preferred.
New features
------------
If you implemented a new feature, your commit message should look like::
- Implemented[ #<number>]: <text>
Where <text> is a short description of the feature you implemented, and
<number> may optionally reference a feature request in the bug tracker. Keep
in mind that the texts will be used for the changelog, so please check the
spelling before committing.
Documentation
-------------
If you extended your documentation, your commit message should look like::
- Documented[ #<number>]: <text>
Where <number> optionally specifies a documentation request, and the text
describes what you documented.
Additional tests
----------------
If you added tests for some feature, your commit message should look like::
- Tested: <text>
Where <text> describes the feature(s) you are testing.
Other commits
-------------
If your commit does not match any of the above rules you should only include a
comment in your commit message or extend this document with your commit
message of desire.

Even we have a contextfree grammar for the language, we implement the trivial parser using regular expressions.

Author(s):

Version:	$Revision: 1236 $
License:	GPL

Method Summary

public void	`__construct( )` Construct parser
protected string	`normalizeWhitespaces( $string )` Normalizes whitespaces in commit message Even not defined in the grammar we do not care about additional newlines or empty lines anywhere.
public array	`parse( $string )` Parse a commit message Parses a commit messages defined by the grammar documented in the class header. the error message.
protected array	`parseStatements( $string )` Parse all statements Parse the statemets like defined in the grammar in the class level docblock.
protected string	`removeComments( $string )` Removes comments from a commit message Removes all valid comments from a commit messages, as they are not of interest for the content extraction.

Methods

__construct

void __construct( )

Construct parser

normalizeWhitespaces

string normalizeWhitespaces( string $string )

Normalizes whitespaces in commit message Even not defined in the grammar we do not care about additional newlines or empty lines anywhere.

Parameters:

Name	Type	Description
`$string`	string

parse

array parse( string $string )

Parse a commit message Parses a commit messages defined by the grammar documented in the class header. the error message.

Parse a commit message Parses a commit messages defined by the grammar documented in the class header. If a parse error occures an exception will be thrown containing the error message. On a successfull parsing process a struct containing a list with all relevant data will be returned, which looks like:

array(
array(
'type' => <type>,
'bug' => <number> | null,
'text' => <text>,
),
...
)

Parameters:

Name	Type	Description
`$string`	string

parseStatements

array parseStatements( string $string )

Parse all statements Parse the statemets like defined in the grammar in the class level docblock.

Parse all statements Parse the statemets like defined in the grammar in the class level docblock. As a result an array is returned with the following structure:

array(
array(
'type' => <type>,
'bug' => <number> | null,
'text' => <text>,
),
...
)

If the commit message could not be parsed a arbitCommitParserException will be thrown.

Parameters:

Name	Type	Description
`$string`	string

removeComments

string removeComments( string $string )

Removes comments from a commit message Removes all valid comments from a commit messages, as they are not of interest for the content extraction.

Parameters:

Name	Type	Description
`$string`	string

Documentation generated on Mon, 05 Apr 2010 14:02:21 +0200 by phpDocumentor 1.4.3