Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
We were calculating "total lines changed" on a per-patch basis, while a
developer's lines changed were max(added,removed) for the entire period
under study. Track developer changed lines per-patch as well...this has
the nice effect of making the percentages add up to 100...
|
|
The primary mainline URL is now torvalds/linux.git rather than
torvalds/linux-2.6.git.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
|
|
Fix the ExtMerge pattern to handle more merge subject forms:
- Multiple branches from URL:
Merge branches '...' and '...' of ...://...
- Merging tags from URL:
Merge tag '...' of ...://...
Merge tags '...' and '...' of ...://...
- Merging URL into specific branch:
Merge ... of ...://... into ...
This allows treeplot to pick up many more external merges, especially in
recent releases, that would otherwise have been treated as internal
merges and often been accounted for in [No tree].
Signed-off-by: James Hogan <james.hogan@imgtec.com>
|
|
This tool really shouldn't be used at this point; it's mostly there for
hysterical interest...
|
|
Looping forever until the disk fills is somewhat antisocial behavior; they
taught me that somewhere in grad school, I'm sure...
|
|
|
|
|
|
...a way to see how many new longer-term developers showed up in each
cycle. Also switch to using accumulator.
|
|
starting with my silly accumulator class.
|
|
|
|
So now I can ask: who were people working for when they committed their
first patch? Also add options to restrict detailed tracking to a subset of
the version history.
|
|
|
|
|
|
|
|
This one just reads through the patch stream, tracking where each developer
is seen for the first and last time. It uses the new grabpatch().
|
|
Some people actually do it...
|
|
|
|
|
|
|
|
Separate out the patch-grabbing functionality to where any utility can use
it. The long-term idea is to switch gitdm itself over to this version as
well.
|
|
I'm tired of trying to be fast and clever. This version is dumb and
heartbreakingly slow - but it works.
|
|
|
|
|
|
|
|
Thanks to Andreas Bießmann <andreas.biessmann@corscience.de> for the idea
and an earlier version of the change.
|
|
...oh, and while I'm at it, make that report actually work right so that a
patch touching three driver files only shows up once at the drivers/ level.
|
|
no functional change
|
|
...useful in combination with -C to see where a specific company is working
within the kernel.
|
|
Dunno why I ever did it that way. No functional change.
|
|
Add a -C option to only look at patches from a specific company.
The options are getting out of control; it would be good to switch to
optparse and add long names for some of them. Someday.
|
|
|
|
Version tracking was used to see who had contributed to the most kernel
releases; not sure it's a long-term-useful feature. The unknown hackers
report helps when trying to improve the database.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
|
|
|
|
The utility as a whole is still somewhat on the fragile side, though.
|
|
Otherwise things crash if the configuration does not provide a file type
map, even if nobody is asking for file type reports.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
This reverts commit 19b718ef41f87f348ac45a90a5c4096ccbd0f7db which breaks
the virtual employer mechanism.
|
|
|
|
...it's 3x faster...
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
Signed-off-by: Germán Póo-Caamaño <gpoo@gnome.org>
|
|
Added first attempt for reporting by file type:
- A general report
- A report aggregated by file type and contributor
- A report aggregated by contributor and file type
Signed-off-by: Germán Póo-Caamaño <gpoo@gnome.org>
|
|
Using an iterator makes the code a bit more 'pythonic'.
Signed-off-by: Germán Póo-Caamaño <gpoo@gnome.org>
|
|
The filetypes can be extended using a configuration files, where
is possible to associate file type and its corresponden regular
expression.
The code includes a script to test the regex without running
gitdm.
Signed-off-by: Germán Póo-Caamaño <gpoo@gnome.org>
|
|
When some projects have migrated from Subversion to Git, there
were several tags that were treated as new commits, which shows
a change in the whole project (code added/removed) when nothing
really happened. For instance, in GNOME a lot svn tags were
catched during the migration, but not all of them.
svn tags in git repositories brings bad stats because double count
commits, and in project with a lot history it may may involve several thousands of source of lines of code.
Signed-off-by: Germán Póo-Caamaño <gpoo@gnome.org>
|
|
Two new dumps were added: per filetype and for every changeset.
It necessary to set a prefix where to dump the data in csv,
because it will be generated one csv file per file type.
Now it is possible to get statistics per code, documentation,
build scripts, translations, multimedia and developers
documentation. This feature is useful for repositories where
there are different types of file, rather than code.
The detailed information does not use the Aggregate parameter.
Signed-off-by: Germán Póo-Caamaño <gpoo@gnome.org>
|
|
Patches as well s Total* and Dates are counted only if the
changeset is not a merge. However, CSCount (ChangeSetCount)
was counting everything, which changes a bit the results.
Signed-off-by: Germán Póo-Caamaño <gpoo@gnome.org>
|
|
The class LogPatchSplitter provides an iterator per patch. This
makes the code cleaner, easier to read and more pythonic.
The class only gets each commit set as lines.
It is possible to test it separately by:
$ git log | python logparser.py | more
Signed-off-by: Germán Póo-Caamaño <gpoo@gnome.org>
|
|
It may distinguish between code, documentation, translations, etc.
Hence, it provides the basic feature to get more accurate reports.
It does not replace the current stats, it is only add the
possibility to generate reports by file type.
This feature was implemented originally by Gregorio Robles in
CVSAnalY http://tools.libresoft.es/cvsanaly/ Gregorio agreed to
add his code here.
Signed-off-by: Germán Póo-Caamaño <gpoo@gnome.org>
|