If the VERSION variable was not filled in, gitstats would run
'git rev-parse' on the repository being examined instead of the
gitstats repository.
Signed-off-by: Sven van Haastregt <svhaastr@liacs.nl>
This should address issue:
Check for gnuplot before running - ID: 3062202
http://sourceforge.net/tracker/?func=detail&aid=3062202&group_id=203965&atid=987711
Signed-off-by: Sven van Haastregt <svhaastr@liacs.nl>
If a custom version of gnuplot would be used by setting the GNUPLOT
environment variable, then still the default gnuplot was called to fill
in the gnuplot version number.
Signed-off-by: Sven van Haastregt <svhaastr@liacs.nl>
When counting authors, do not fall back to 0 if the git call fails. Zero
authors causes ZeroDivisionError later on otherwise. This reverts an old change
for msysgit on win32, introduced in a01045f2480a21f28dd90e278b4f560020a97b9e.
It should no longer be necessary.
Git versions with commit 7f814632f5d4d7af9f4225ece6039dbc44e03079 print the
stat summary output slightly different. There were two changes that affect
GitStats:
a) Singular forms of files/insertions/deletions may be used
b) The number of counts is now variable ranging from 1 to 3:
1: only files changed if file count is 0
2: if either insertions or deletions are 0 (not if both are)
3: where files,insertions and deletions are >0
or both insertions and deletions are 0
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
Make the units on par with active commit days. Previously a new project
committed to yesterday at 23:00 and today at 1:00 would have an age of 1 day
but 2 active days.
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
A hard-to-spot bug where the total number of commits for a tag was always set
to the number of commits that one of the commiters did and not the cumulated
sum over all commiters.
[hoxu@users.sf.net: created a commit from diff and description sent by Thomas]
Fix for KeyError being generated if a month has commits but for some reason no lines changed
Example of exception
[1.17747] >> gnuplot --version
Traceback (most recent call last):
File "./gitstats", line 1373, in <module>
g.run(sys.argv[1:]
File "./gitstats", line 1365, in run
report.create(data, outputpath)
File "./gitstats", line 841, in create
f.write('<tr><td>%s</td><td>%d</td><td>%d</td><td>%d</td></tr>' % (yymm, data.commits_by_month[yymm], data.lines_added_by_month[yymm],
data.lines_removed_by_month[yymm]))
KeyError: '2010-08'
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
Stats are calculated for months of year and years. Activity page in
sections 'Commits by year/month' and 'Commits by Year' are enhanced by
this statistic.
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
If you tried to pass only -c commit_begin=something this would
always return HEAD in any case since commit_end was set to ''.
Defaulting commit_end to HEAD makes getcommitrange() function work as it
should.
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
Do not consider a dot in path a filename extension.
'highlight.js/LICENSE' was recognized as 'js/LICENSE' extension erroneously.
Fixes SourceForge bug #3221520.
Thanks-to: Alexander Gladysh <agladysh@users.sourceforge.net>
We collect and accumulate data based on the order of the output of "git
log", which is not necessarily ordered by timestamp. Adding --date-order
should improve the situation, but isn't sufficient at least on git.git's
repository.
In addition, when encountering a date that is prior to the last one
encountered, we change it to be the last encountered date. A better
solution would be to actually order the lines before starting to count.
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
Commit timestamps can be in backwards order (when applying patches &
cherry-picking in reverse order), so we don't want author age to be negative
(was in gitstats case too :)
Initial attempt to make gitstats create cumulative statistics for multiple
repos (the case of a single project consisting of more than just one git
repository.)
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
Old versions of gnuplot produce garbage if the author's name contain
non-ascii, but gnuplot 4.4 seems to handle it just fine.
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
Don't compute per-author information with --first-parent
While it's fine to compute project-wide informations (LOC) on a linear
history, we don't want to assign added lines of code to the user doing
a merge when the code was initially written by someone else on a
branch.
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
Gnuplot version 4.4 renders text within the drawing area with "set
xtics rotate angle 90". According to
http://newsgroups.derkeiler.com/Archive/Comp/comp.graphics.apps.gnuplot/2010-08/msg00079.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586513
this is a feature, not a bug, but "set xtics rotate" give the expected
behavior everywhere (text from down to top, below the graph).
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
Set image size with "set terminal size", not "set size".
Recent versions of gnuplot understand "set size" as the amount of
space to use within the canava size. "set size 1,0.5" was therefore
creating large images with the top half being blank.
set terminal size works as expected at least with gnuplot 4.4 and 4.2.
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
gitstats is dual-licensed under GPLv2/GPLv3, so naturally the contributions are
asked to be GPLv2+.
Thanks-to: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
The following command used to fail because git shortlog has some witty magic to
decide the behaviour based on whether stdin is a terminal:
./gitstats /repo /dst < /dev/null
effectively causing a lot of shell scripts calling gitstats to fail with
"Division by zero" in author statistics.
Thanks-to: Bertrand Jacquin <beber@meleeweb.net>
Thanks-to: Sylvain Rabot <sylvain@abstraction.fr>
When enabled, the lines of code statistics are collected from linear history.
The downside is that commits of feature long feature branches appear only at
the point where a merge commit is made.
If disabled (old behaviour), the problem is that if two branches contain the
same changes (for example, removal of same lines), the statistics get skewed.
Fixes line count statistics for this example repository:
git://github.com/septract/jstar.git
Thanks-to: Radu Grigore <radugrigore@users.sourceforge.net>
This patch changes Makefile to use perl for version number replacement to fix
'make install' on Darwin. The problem is that GNU sed and sed on Darwin (and
probably on BSDs) behave differently with regards to the '-i' command line
option.
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Heikki Hokkanen <hoxu@users.sf.net>
Heikki Hokkanen
Sven van Haastregt