This is because of the patch committed with revision 68a6e90228. As
Python 3 stores unicode strings by default, we need to convert them back.
This change will hopefully fix it once and for all.
Specific commits can now be filtered by using;
-x, --exclude="revision:<SHA-1>"
Like with all other filtering in gitinspector, regular expressions are
supported. Likewise, multiple revisions can be specified using a comma or
by simply supplying multiple exclude parameters.
As usual, both the commit module and blame module take this filtering into
account.
Error out gracefully when gitinspector is called with a path that does not
point to a git repository, instead of printing a stack trace.
Signed-off-by: Christian Kastner <debian@kvr.at>
Signed-off-by: Adam Waldenberg <adam.waldenberg@ejwa.se>
For example, on a FreeBSD system Python can be installed in
/usr/local/bin/python.
Some systems have multiple interpreters installed in a variety of
locations. The attached patch corrects the problem by using the
env(1) command to run Python.
Signed-off-by: Adam Waldenberg <adam.waldenberg@ejwa.se>
The email search regular expression in the git-blame output can be tripped
by a similar pattern appearing in the source code. The supplied patch
fixes the problem.
Signed-off-by: Adam Waldenberg <adam.waldenberg@ejwa.se>
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.
This works in the same manner as the other filtering available in the HTML
view. The minor authors of the responsibilities view equal the minor
authors of the blame view.
Previously, an email for a specific author was collected whenever some
insertions/deletions were detected in an active or valid extension. This
was introduced with the addition of gravatars.
This had the side-effect that if #author1 committed some rows to a file
with an inactive or non-valid extension and #author2 later moved some of
those rows into an active or valid extension, those rows could still
belong to #author1. Consequently, when associating the author name with
an email in the blame phase, there would not be any stored email for
#author1 and no email would be associated with that author or those blamed
lines.
Emails are now (instead) always stored and associated with an author
regardless of the work or files analyzed.
This is unnecessary as there is a get() function inside the changes module
to fetch an object of this class, so we can fetch this directly in
BlameOutput.__init__().
The error message when using an incompatible version of
Python contains a typo.
Signed-off-by: Chris Ring <chris@ringthis.com>
Reviewed-by: Adam Waldenberg <adam.waldenberg@ejwa.se>
Previously; the __get_size_windows__() function could return "None",
whenever the terminal size couldn't be determined; something which broke
the execution.
There was some chance for misbehavior under Linux as well.
Previously, gitinspector always tried to merge authors with the same name
(independently of the email). This behavior tends to (for the most part)
help in projects missing a .mailmap file. Often; authors commit under the
same name, but with different emails on different computers (if they for
example have a work email on their office desktop).
Whenever different e-mail addresses are used by an author; gitinspector
will use the last email it finds and will generate a gravatar from that
email address. This behavior was chosen because authors mostly do not tend
to create a gravatar image for their old email accounts (but often have
one in their newer ones).
References to gravatar images are generated with HTML and XML outputs only
as these are the only formats where referencing gravatars makes sense
right now. The HTMLEmbedded format, for example, does not link to any
gravatars as that format prohibits the use of external links.
To accommodate the new images; the width of the generated HTML page has
been slightly increased. However, the HTML page should still fit on a
1280 display.
This is a better solution than simply relying on ValueError and also
helps us to maintain compatibility with all our other exceptions (it gives
us a msg attribute that we can access when catching the error).
Also localized the string for InvalidRegExpError.
This was fixed by storing the exception string manually inside each
exception class. The error message is now stored in exception.msg instead
of relying on __str__(). It seems the normal behavior (by printing exceptions
directly) is broken in Python 2. It *does* work in Python 3, but this is
because it always handles everything as unicode.
The support for optional boolean arguments is the same; but uses
getopt instead of optparse.
The whole adventure with optparse was a giant waste of time and just
forced us to monkey-patch optparse with some very ugly solutions in order
to make it do what we wanted; thus it was better to switch back to the
more low-level getopt module.
To accomplish this; a optval.gnu_getopt() function was added that is a
duplicate of the original getopt.gnu_getopt function but with support for
optional arguments.
A long option which accepts an optional argument is denoted with
arg:default_value in the long_options string.
In the end, this solution feels much better than the one with optparse.
If gitinspector was not executed standing in the root directory of the
git repository (or with a git root specified at the command line),
"git ls-tree" would not find all files properly.
In the process, the new strings were also translated to Swedish. To
properly handle localized string constants, a new function "N_()" was
added which can be supplied to xgettext when collecting strings.
The default behaviour is now not to localize the output, only the help
text and error messages (all the user interaction).
The way localized messages are fetched in the modules has been modified
as well; to allow for the ability to enable and disable the localization.
Just like in many GNU tools, it is now possible to pass an optional
boolean to some of the flags of gitinspector in the form;
--flag[=BOOL]
This gives us the ability to override options set via git-config.
For example; say we did the following:
git-config --global inspector.timeline true
We could then override this setting when running gitinspector by supplying:
./gitinspector.py --timeline=false
Implementing this was not a trivial task, as no command-line parser in
Python supports this by default (getopt, optparse, argparse). In order to
properly handle optional boolean arguments; some clever patching had to
be done to the command-line in combination with a callback function that
can handle boolean strings. To maintain compatibility with Python 2.6,
this was implemented using optparse (instead of argparse).
This function moves most of the logic of handling comments into the
comment module itself, thus avoiding duplicated code and allowing for
a cleaner solution.
Adam Waldenberg
Kamila Chyla
Philipp Nowak
Bill Wang
Dmitry Dzhus
Luca Motta
Yannick Moy
Christian Kastner
Jon Warghed
Diomidis Spinellis
Chris Barry
Chris Ring