This is accomplished by color coding the rows of the violations in the
following manner:
minimal violations: light green
minor violations: green
medium violations: yellow
bad violations: light-red
sever violations: red
Naturally, the zebra coloring of the rows is still being maintained.
Each metrics section now has a header with proper coloring. Furthermore,
every other row of the outputted violations are colorized in order to
improve readability.
The calculation is rather simple and is not meant to be a reflection of
McCabes's cyclomatic complexity number. Instead, it is an approximation,
implemented in a more general way and supporting many different languages
through the use of regular expression matching.
The initial languages supported in this metric are: Java, JavaScript, C,
C++ and Python.
If anyone needs support for some other language, patches to the metric
module (metrics.py) are welcome.
The base name of the returned absolute path is also the name of the
repository from which the statistics were gathered. We will use this in
the generated reports.
This makes sure that the most recent email of an author is always used when
generating the gravatar. It also makes sure that the mappings between
author<->email are correct (and recent).
For now, we return 100 % whenever an author is not found to have any
entries in the changes log. This can happen whenever an author uses the
same email but with different author names.
The solution would probably be to consider these commits to belong to the
same person and merge the results.
This will require some additional changes to the code and a redesign in
the way that author names and emails are mapped.
This completes the "code stability" functionality.
While code stability is a percentage (zero and up) that reflects the
stability of the authors code, the age value is a pseudo-value describing
the average age of all the authors rows. The older the code, the higher
the value.
Code stability can sometimes be above 100%, depending on the way git
calculates insertions and blamed rows.
The supported protocols are file://, git://, http://, https:// and ssh://.
Whenever one of the above prefixes are detected in the repository name,
"git clone" is used to clone the repository into a temporary directory.
When "git clone" is called, it's output is redirected to stderr; meaning
that redirection of stdout to a file functions just as before.
If "git clone" fails for some reason, gitinspector will exit; returning
the error code from the "git clone" command.
Whenever filtering of author or email was enabled, problems could arise
when calculating comments percentage. Did some reshuffling of the logic;
resolving it.
It was not taking the caret (^) character into consideration when --since
was being specified, something which resulted in an excess of attributed
rows.
With this easy fix, the behavior should now be "correct".
This is flag should not be needed anymore, as gitinspector always uses
a reference point such as HEAD or some reivision when looking into the
repository (never the file structure directly).
Instead of specifying -x (or --exclude) multiple times, it is possible to
specify multiple filtering rules by separating each rule with a comma (,)
character. This enables the new support for filtering authors and email to
work in conjunction with git-config.
As a side effect, this means that we reserve the comma character for
internal use in gitinspector and that it can't be used in any regular
expression or filtering rule. However, this is not a big problem.
Of course, specifying -x multiple times (like before) is still supported.
To access this functionality; the -x flag can now be called in the
following ways:
-x file
-x file:<file>
-x author:<author name>
-x email:<email>
Just passing -x file will presume that the filtering rule is intended for
a file (just like the previous behavior).
All the filtering is case sensitive (even filtering by email) in order to
not break any regular expressions used. Case-insensitive matching can
instead be easily achieved with the appropriate regular expression.
To get reversed filtering (excluding everything not matched within -x) a
regular expression with the a syntax such as '^(?!<rule>)' can be used.
