{"thread":{"id":"14744","subject":"[ANNOUNCE] GitStats development finished (WRT GSoC)","startedAt":"2008-07-29T22:11:48Z","lastAt":"2008-07-30T15:41:56Z","messageCount":5,"participants":["Sverre Rabbelier","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"85524","messageId":"bd6139dc0807291511v2d70d549r3682291eb10a745d@mail.gmail.com","threadId":"14744","inReplyTo":null,"subject":"[ANNOUNCE] GitStats development finished (WRT GSoC)","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-29T22:11:48Z","receivedAt":"2008-07-29T22:11:48Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"Heya,\n\nI leave to the USA this Friday, and because of US tax laws I would\nhave to pay an insane amount of tax for just 2 weeks of development. I\nhave agreed with my mentor a while a go that I would finish up GSoC\nbefore I left, that way avoiding having to pay US taxes. (Over here in\nthe Netherlands I don't have to pay tax over the $4500 because I\ndidn't make >6000 euro this year, the joys of being a student.) As a\nresult it is quite clear what GitStats will look like at the end of my\nGSoC. I am going to continue working on it though, I am especially\ninterested in getting the '--follow' part of 'git log' working in such\na way that it can be incorporated into GitStats. As such, here is a\nsummary of what GitStat is at the moment. From the documentation:\n\n$ cat gitstats-*\nsyntax: stats.py author \n\nThe purpose of the author module is to gather statistics\nabout authors, and to aggregate this information to provide\ninformation about all the authors of a repo.\n\nCurrently the available metrics in the author module are\nthe following:\n* Determine how many changes an author made (making a\n distinction between lines added and lines deleted), and\n record this per author, for all files in the repository.\n It is possible to get this data for one specific author,\n (although data for all authors will still be gathered,)\n because the result is stored per author.\n\n* Determine how many commits an author made that affected\n a specific file. This metric is less granular, but a lot\n faster. To retreive the more granular result, one could\n simply iterate over the result of the above metric for\n each author, and take only the data for the file one is\n interested in.\n\n* Aggregate the information from the first metric, adding\n up the statistics from each author. This provides a more\n general 'file activity' metric and is a nice example of\n how an existing metric can be modified to do something\n seemingly unrelated.\n\nThis module does not define any auxillery functions.\n\nsyntax: stats.py branch \n\nThe purpose of the branch module is to gather statistics\nabout branches, or related to branches.\n\nCurrently the available metrics in the branch module are\nthe following:\n* Which of the branch head does a commit belong to\n What this metric does is walk down the ancestry of the\n target commit and increase the 'dilution' by one or each\n merge it finds. The exception applies that when following\n the 'primary' parent of the merge (e.g., the branch\n recorded as the one the merge commit was made on), the\n dilution is not increased. As such, if the target commit\n is made on a branch, and then later on it's dilution\n is calculated, it will have 0 dilution for that branch.\n The branch with the lowest dilution is deemed to be the\n branch that the commit belongs to most.\n Note: In git there is no 'main' branch, as such any and\n all branches branches that 'branched off' after the\n target commit will also have dilution 0.\n\nIt also defines the following auxillery functions:\n* Retreive the name of a commit if it is a the head of a\n branch. This can be seen as the reverse of 'rev-parse'\n for branch heads. This is used internally to provide the\n user with a sensible name when telling them which branch\n a commit belongs to.\n\n* List all the branches that contain a specific commit,\n optionally searching through remote branches as well as\n optionally not filtering at all. This is used internally\n to not search through branches that do not contain the\n target commit.\n\nsyntax: stats.py bug \n\nThe purpose of the bug module is to gather statistics on\nbugfixes within the content, and to aggregate this\ninformation to provide with a report of the last N commits.\n\nCurrently the available metrics in the bug module are the\nfollowing:\n* Determine whether a specific commit is a bugfix based on\n other metrics. When one of the metrics is 'positive',\n that is, it's return value indicates that the examined\n commit is a bugfix, the 'bugfix rating' is increased by\n a pre-configured amount. This amount can be specified per\n metric, and can be set to '0' to ignore it.\n\n* Aggregate the above metric over the past N commits. Also,\n when running the above metric on more than one commit,\n cache the result of calls to the git binary so that the\n execution time is reduced. This means that the execution\n time is not directly proportional to the size of the\n repository. (Instead, there is a fixed 'start up' cost,\n after which there is a 'per commit' cost, which is\n relatively low.)\n\nThis module does not define any auxillery functions.\n\nsyntax: stats.py commit \n\nThe purpose of the commit module is to gather statistics\nabout commits, or related to commits, with the exception\nof things related to diffs (only retrieving the raw diff is\nin this module).\n\nCurrently the available metrics in the author module are\nthe following:\n* Find all the commits that touched the same paths as the\n specified commit. This is implemented by passing the\n result of the 'paths touched' auxillary function to the\n 'commits that touched' auxillary function. See below.\n\n* Retrieve the diff of a commit, either with or without\n context, and optionally ignoring whitespace changes. This\n method also works for the root commit (by making use of\n the '--root' option to 'diff tree'.\n\n* Show only commits of which the commit message, and/or the\n commit diff, match a specific regexp. This is a simple\n reimplementation of 'git log -S' and 'git log --grep'. It\n is preferable to instead use the options native to\n 'git log', than to use this slower version.\n Note: the regexps for the 'commit message' and the\n 'commit diff' may be different.\n\nIt also defines the following auxillary functions:\n* Print a commit in a 'readable' way, this is by default\n 'git log -1 --name-only'. By the way of an environmental\n variable ('GIT_STATS_PRETTY_PRINT'), it can be made to\n instead use 'git log -1 --prety=oneline' by setting the\n variable to 'online'.\n\n* Retrieve all the paths that a specific commit touches,\n this is used internally to limit the commits that have\n to be searched when looking for a merge. That is done by\n passing the output of this method to the one described\n below.\n\n* Find all commits that touched a list of files, optionally\n treating the paths as relative to the current working\n directory.\n\nsyntax: stats.py diff \n\nThe purpose of the diff module is to gather statistics\nabout diffs, or related to diffs.\n\nCurrently the available metrics in the diff module are the\nfollowing:\n* Determine whether two commit diffs are equal, optionally\n checking whether they are reverts instead. It is also\n possible to just look at what lines were changed (and\n ignore the actual changes).\n\n* Find all commits that are reverted by the specified\n commit by first retrieving the touched files, and then\n examining all the commits that that touch the same files.\n\nIt also defines the following auxillery functions:\n* Parse a raw commit diff and store it on a hunk-by-hunk\n basis so that later on it can be examined more carefully\n by other tools. Line numbers are optionally included so\n that one can use those. For example, by comparing all the\n added hunks with the deleted hunks of a second commit,\n and vise versa, one can check for (partial) reverts.\n\nsyntax: stats.py index \n\nThe purpose of the index module is to gather statistics\nabout the index, or related to the index.\n\nCurrently the available metrics in the index module are the\nfollowing:\n* List all the commits that touch the same files as the\n staged files. This can be useful to find out which commit\n introduced the bug fixed in this commit (by piping the\n output of this method to one that looks at which lines\n were touched for example).\n\nIt also defines the following auxillery functions:\n* Get all the staged changes (optionally ignoring newly\n added files). This is used internally to find all the\n commits that touched the same files as those that are\n currently staged.\n\nsyntax: stats.py matcher \n\nThe purpose of the matcher module is to compare hunks\nwithin one diff to one another, and determine whether there\nis any code being moved around.\n\nCurrently the available metrics in the index module are the\nfollowing:\n* Try to find a match between the hunks in one diff, so\n that code moves can be detected. This makes use of the\n 'diff size calculation' described below.\n\nIt also defines the following auxillery functions:\n* Calculate the size of a diff, only counting the amount\n of lines added, and the amount of lines deleted. This can\n be used to determine a best 'interdiff' (the shortest one\n is the best one), when searching for two hunks that are\n moved around.\n\nsyntax: stats.py \n\nAvailable commands:\n author Activity for one author, file, or project\n branch In how far a commit belongs to a branch\n bug Determine whether a commitis a bugfix\n commit Basic functionality already present in git\n diff Compare two diffs and find reverts\n index Find which commits touched the staged files\n matcher Try to match hunks in a diff to find moves\n test Run the unittests for GitStats\n\nThe stats.py module is the main entry point of GitStats,\nit dispatches to the commands listed above. When no\narguments are passed, it automatically runs the command\nwith '--help' so that a usage message is shown for that\ncommand.\n\nEach of the modules it uses as subcommands defines a\n'dispatch' function that is called with the users arguments\n(with the exception of the first, which is the name of the\ncommand executed). If anything should be returned to the\nsystem, the dispatch method should return this value.\n\nTo run properly it requires the git_stats package to be\na subdirectory of the directory it resides in. That is,\nyour directory tree should be something like this:\n.\n|-- git_stats\n| `-- \n|-- scripts\n| `-- \n|-- t\n| `-- \n`-- stats.py\n\nsyntax: stats.py tests \n\nThe purpose of the tests module is to make available the\nunittests for GitStats to external programs. It may be\nused to run the unittests for GitStats from for example\na shell script. It's output is made to match the git\nregression test suite.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85588","messageId":"7vabfz97fl.fsf@gitster.siamese.dyndns.org","threadId":"14744","inReplyTo":"bd6139dc0807291511v2d70d549r3682291eb10a745d@mail.gmail.com","subject":"Re: [ANNOUNCE] GitStats development finished (WRT GSoC)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-30T07:07:10Z","receivedAt":"2008-07-30T07:07:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Rabbelier\" writes:\n\n> ... As a\n> result it is quite clear what GitStats will look like at the end of my\n> GSoC. I am going to continue working on it though, I am especially\n> interested in getting the '--follow' part of 'git log' working in such\n> a way that it can be incorporated into GitStats. As such, here is a\n> summary of what GitStat is at the moment. From the documentation:\n\nWonderful.\n\n> syntax: stats.py bug \n>\n> The purpose of the bug module is to gather statistics on\n> bugfixes within the content, and to aggregate this\n> information to provide with a report of the last N commits.\n\nCan't wait running this, especially in conjunction with the \"author\" stuff\n;-)\n"},{"id":"85593","messageId":"bd6139dc0807300212r67ccb849i542e490c8cd00953@mail.gmail.com","threadId":"14744","inReplyTo":"7vabfz97fl.fsf@gitster.siamese.dyndns.org","subject":"Re: [ANNOUNCE] GitStats development finished (WRT GSoC)","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-30T09:12:47Z","receivedAt":"2008-07-30T09:12:47Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Wed, Jul 30, 2008 at 09:07, Junio C Hamano wrote:\n> Can't wait running this, especially in conjunction with the \"author\" stuff\n> ;-)\n\nHehe, don't expect too much of it yet though (the 'bug' module that\nis), there won't be any \"99% of the bugs come from Dscho\" yet :P.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"85628","messageId":"alpine.LSU.1.00.0807301621570.3486@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"14744","inReplyTo":"bd6139dc0807300212r67ccb849i542e490c8cd00953@mail.gmail.com","subject":"Re: [ANNOUNCE] GitStats development finished (WRT GSoC)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-30T14:22:22Z","receivedAt":"2008-07-30T14:22:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 30 Jul 2008, Sverre Rabbelier wrote:\n\n> On Wed, Jul 30, 2008 at 09:07, Junio C Hamano wrote:\n> > Can't wait running this, especially in conjunction with the \"author\" \n> > stuff ;-)\n> \n> Hehe, don't expect too much of it yet though (the 'bug' module that is), \n> there won't be any \"99% of the bugs come from Dscho\" yet :P.\n\nSo what should I expect? What does it show?\n\nCiao,\nDscho\n"},{"id":"85640","messageId":"bd6139dc0807300841n3e1670cdie2cd3fec47ab0db4@mail.gmail.com","threadId":"14744","inReplyTo":"alpine.LSU.1.00.0807301621570.3486@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: [ANNOUNCE] GitStats development finished (WRT GSoC)","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-30T15:41:56Z","receivedAt":"2008-07-30T15:41:56Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Wed, Jul 30, 2008 at 16:22, Johannes Schindelin\n wrote:\n> On Wed, 30 Jul 2008, Sverre Rabbelier wrote:\n>> Hehe, don't expect too much of it yet though (the 'bug' module that is),\n>> there won't be any \"99% of the bugs come from Dscho\" yet :P.\n>\n> So what should I expect? What does it show?\n\nAtm I have 4 'metrics' (4 out of the 5 suggested ones), namely:\n\n* Does a commit belong to a specific branch. This can be used, for\nexample, to mark commits on 'maint' as bugfixes with 99% reliability\n(you need to make sure your regexp catches all branches you are\ninterested in, when Junio splits of '1.5.6.4' of maint, it might list\n'1.5.6.4' instead of 'maint', as they both point at the same ref).\n* Does a commit fully revert another one (e.g., make commit A, do 'git\nrevert A', it will detect that commit as reverting A).\n* Does the commit message match a certain regexp (e.g., if it contains\nthe word \"fixes\", it is likely a fix).\n* Does the commit diff match a regexp (e.g., a change from\n\"test_expect_failure\" -> \"test_expect_success\")\n- (not tweaked yet) Does a commit partially revert another one, this\nneeds some tweaking, otherwise small changes are quickly seen as\nsimilar. (If you have two unrelated one-lines, and you set it to\nignore one difference...)\n\nYou have to configure a few things to get it running (for example, you\nneed to tell it what branch is your maintenance branch, if any). You\ncan also configure how valued each metric is (you can say \"if it's in\n'maint', add 5 points, but if it's a revert, add 10, and add only 1\npoint if it matches this regexp). Configuration is trivially done with\n'git config GitStats.key value\".\n\n(Will add the above to the bug module's documentation)\n\nIf anyone comes up with any more metrics to determine whether\nsomething is a bug it can be easily hooked in.\n\n-- \nCheers,\n\nSverre Rabbelier\n"}]}