{"thread":{"id":"12789","subject":"[SoC RFC] git statistics - information about commits","startedAt":"2008-03-21T08:52:38Z","lastAt":"2008-03-23T21:32:57Z","messageCount":12,"participants":["alturin marlinon","Junio C Hamano","Martin Langhoff","Johannes Schindelin","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72582","messageId":"bd6139dc0803210152o529f3b4fi15c515f5385d8f88@mail.gmail.com","threadId":"12789","inReplyTo":null,"subject":"[SoC RFC] git statistics - information about commits","fromName":"alturin marlinon","fromEmail":"alturin@gmail.com","sentAt":"2008-03-21T08:52:38Z","receivedAt":"2008-03-21T08:52:38Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"Heya,\n\nWith regard to Google Summer of Code's application deadline closing in\nfast, I could really appreciate it to get some feedback on my\napplication so far. Especially on what parts of this idea would be\nappreciated the most, and what parts could be done without.\n\nI have been using git on several projects so far and am very happy\nwith the way it does things.\nWhen looking at TortoiseSVN I noticed that it comes with a\n'statistics' button that allows you to see which users have done what.\nEven though it is limited in that it can only show how many commits\nwere made, I think this is an important feature to any VCS. I became\naware of the importance of statistics during a project at my\nUniversity (we had to use Subversion). During the project I noticed I\nused these statistics to talk about fair distribution of work, and it\nreally helped to get everybody's nose pointing in the right direction.\nKeeping that in mind, I tried to get such statistics from git. Git\nprovides a 'commits per user' feature under 'git shortlog -s -n -c\nmaster' (note the order of the switches).\n\nConsider Ohloh, an external tool that provides commit information\nabout contributors to a project.\nIt provides with a quick over of all contributors to a project, and\nwhat their contribution has been so far. At the moment git does not\nhave anything similar, even though all the data needed for such an\nanalysis is present. Integration with gitk and git-web would allow the\ndata to be presented in a clear and informative way.\n\nAnother bit of interesting information would be 'who is maintaining\nthis code?'. Such information is especially useful when trying to\ndecide whom to send a copy of a patch. Consider that git already\ncontains the e-mail address of each developer that maintains a certain\nbit of code (this information is included in each commit). If we now\nfind out who maintains the code that was changed in a commit\ngit-format-patch could automatically include them in the cc: field.\nSimilarly, one might be interested in what code a maintainer is\ncurrently working on.\n\nIn a more broad sense it might be interesting to determine what part\nof the code is most actively worked on, and what part of the code is\nmost stable. This is most interesting when deciding whether an API is\nready to be published. (If the API is changing a lot it might be\nbetter to wait till it has stabilized.) This information could even be\nused to find 'edit wars'. (In which a part of the code is changed over\nand over again.)\n\nMy plan for this summer is to create a 'statistics' feature for git.\n\nIt would provide the following functionality:\n* Show how many commits a specific user made.\n* Show the (average) size of their changes (in lines for example).\n* Show a 'total diff', that is, take the difference between the source\nwith, and without their changes, including its size (with for example\na -c switch).\n* Show which contributors have contributed to the part of the code\nthat a patch modifies.\n* Show what part of the code a maintainer is working on the most.\n* Define an output format for this information that can be used by\nother tools (such as gitk and git-web)\n* (Optional) Integrate all this information with gitk and git-web.\n\nImplementation would probably start out with python scripts since\nthose are easy to modify and combine with other scripts. As milestones\nare reached in time, or ahead of time, attention could be shifted to\nconverting these to C and combining them with the rest of git. When\nthe other milestones are finished time could be spent on using the\nnewly added features in gitk and/or git-web.\n\nTo achieve all these milestones heavy usage can be made of existing\ngit commands. For example, getting the total amount of commits from a\nmaintainer can be achieved with the less-than-intuitive 'git shortlog\n-s -n -c master', providing an alias to this command would make it\neasier to use this functionality. Since other git commands will be\nused a lot, performance may suffer as a result of piping/parsing\nresults from one command to another. When a feature is converted to C\nlater on attention could be given to directly passing the result from\none function to another.\n\nDetermining which users have been active on a file git's built in\n'blame' functionality can be used. Git blame is very fast it would be\nno problem to make extensive use of it in determining maintainer\nfocus. In a similar way it can be used to determine who has worked on\na file recently.\n\nI am a Dutch student, doing my Bachelor at 'Delft University of\nTechnology'. I study 'Technische Informatica', Dutch for 'Computer\nScience'. Even before starting fourth grade in Highschool I learned\nC++ so that I could help out as a coder on a MUD (Multi User Dungeon).\nIn grade four through six I followed the optional \"Informatica\" (a\nHigh school version of 'Computer Science') course. We learned Java and\nSQL, nothing too difficult, but it got me wanting to learn more. I\nlearned to learn other languages on my own, probably valuable thing I\nlearned.\n\nI have used git on numerous projects so far, although some of its more\nelaborate features I am not yet familiar with. My motivation for this\nparticular idea I have described above. Enjoying working with git made\nme want to work on it as my Google of Summer project. Knowing that an\noriginal idea has more chance of being selected I spent a lot of time\nlooking for ways to improve git worth a GSoC of coding. I'm really\nlooking forward to coding for git and I think GSoC would be an awesome\nintroduction to it's codebase but also to contributing to a large\nproject.\n\nThank you for your time and attention,\n\nSverre Rabbelier\n(SRabbelier on #git)\n"},{"id":"72587","messageId":"7vmyospgz7.fsf@gitster.siamese.dyndns.org","threadId":"12789","inReplyTo":"bd6139dc0803210152o529f3b4fi15c515f5385d8f88@mail.gmail.com","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-21T09:24:28Z","receivedAt":"2008-03-21T09:24:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"alturin marlinon\" writes:\n\n> My plan for this summer is to create a 'statistics' feature for git.\n>\n> It would provide the following functionality:\n> * Show how many commits a specific user made.\n> * Show the (average) size of their changes (in lines for example).\n> * Show a 'total diff', that is, take the difference between the source\n> with, and without their changes, including its size (with for example\n> a -c switch).\n> * Show which contributors have contributed to the part of the code\n> that a patch modifies.\n> * Show what part of the code a maintainer is working on the most.\n> * Define an output format for this information that can be used by\n> other tools (such as gitk and git-web)\n> * (Optional) Integrate all this information with gitk and git-web.\n\n* Within reasonable amount of time suitable for interactive use, if you\n intend it to work with gitk.\n\nWhat's the ballpack performance goal for e.g. post 2.6.12 kernel history\nwhich is about 85k commits, 3800 authors, 24k files?\n\n* Who contributed the most code that needed the many fix-ups on top?\n\n* Which part of the codebase had the most commits that had \"oops, screwed\n up, I am fixing this but this is a tricky code\" fixes?\n"},{"id":"72593","messageId":"46a038f90803210651offecf20h9ea527b610c8769f@mail.gmail.com","threadId":"12789","inReplyTo":"7vmyospgz7.fsf@gitster.siamese.dyndns.org","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2008-03-21T13:51:26Z","receivedAt":"2008-03-21T13:51:26Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Fri, Mar 21, 2008 at 5:24 AM, Junio C Hamano wrote:\n> * Which part of the codebase had the most commits that had \"oops, screwed\n> up, I am fixing this but this is a tricky code\" fixes?\n\nHow the hell do we spot that one? ;-)\n\n\nmartin\n-- \n martin.langhoff@gmai.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"72594","messageId":"alpine.LSU.1.00.0803211455550.4124@racer.site","threadId":"12789","inReplyTo":"46a038f90803210651offecf20h9ea527b610c8769f@mail.gmail.com","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-21T13:56:38Z","receivedAt":"2008-03-21T13:56:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 21 Mar 2008, Martin Langhoff wrote:\n\n> On Fri, Mar 21, 2008 at 5:24 AM, Junio C Hamano wrote:\n> > * Which part of the codebase had the most commits that had \"oops, screwed\n> > up, I am fixing this but this is a tricky code\" fixes?\n> \n> How the hell do we spot that one? ;-)\n\nIt would probably involve finding pieces of code that were changed \nmultiple times, i.e. lines of code that did not survive for many commits.\n\nCiao,\nDscho\n"},{"id":"72596","messageId":"m3wsnwuo6y.fsf@localhost.localdomain","threadId":"12789","inReplyTo":"bd6139dc0803210152o529f3b4fi15c515f5385d8f88@mail.gmail.com","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-21T14:49:49Z","receivedAt":"2008-03-21T14:49:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"alturin marlinon\" writes:\n\n> Consider Ohloh, an external tool that provides commit information\n> about contributors to a project.\n\nOhloh currently doesn't make the statictics part of Ohloh code\navailable: only ohcount[1] is open source.\n\nBut there is other similar project, but is fully open source:\nGitStat[2]. It is also geared towards using it from web browser;\nnevertheles it is worth examining to avoid \"reinventing the wheel\".\n\nReferences:\n[1] http://labs.ohloh.net/ohcount\n[2] http://tree.celinuxforum.org/gitstat/\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"72695","messageId":"7v3aqik0nz.fsf@gitster.siamese.dyndns.org","threadId":"12789","inReplyTo":"7vmyospgz7.fsf@gitster.siamese.dyndns.org","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-22T19:40:16Z","receivedAt":"2008-03-22T19:40:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> \"alturin marlinon\" writes:\n>\n>> My plan for this summer is to create a 'statistics' feature for git.\n>>\n>> It would provide the following functionality:\n>> * Show how many commits a specific user made.\n>> * Show the (average) size of their changes (in lines for example).\n>> * Show a 'total diff', that is, take the difference between the source\n>> with, and without their changes, including its size (with for example\n>> a -c switch).\n>> * Show which contributors have contributed to the part of the code\n>> that a patch modifies.\n>> * Show what part of the code a maintainer is working on the most.\n>> * Define an output format for this information that can be used by\n>> other tools (such as gitk and git-web)\n>> * (Optional) Integrate all this information with gitk and git-web.\n>\n> * Within reasonable amount of time suitable for interactive use, if you\n> intend it to work with gitk.\n>\n> What's the ballpack performance goal for e.g. post 2.6.12 kernel history\n> which is about 85k commits, 3800 authors, 24k files?\n>\n> * Who contributed the most code that needed the many fix-ups on top?\n>\n> * Which part of the codebase had the most commits that had \"oops, screwed\n> up, I am fixing this but this is a tricky code\" fixes?\n\nA couple more food-for-thought.\n\n* Figure out which blocs of lines (not necessarily the whole files) relate\n to each other by noticing that they are often modified in the same\n commit.\n\n For example, if you find that the earlier part of a file A.c is updated\n often only by itself, but many other commits often modify the later part\n of A.c and another file B.c at the same time, it might suggest that a\n better reorganization of the code is to split the later part of A.c and\n move it to B.c.\n\n* Who are early birds and who are late night owls? Who are day-job\n contributors and who are weekenders?\n\n* Identify \"buggy commits\" from history, without testing. Zeroth order\n approximation is that the lines it introduced were later rewritten by\n other later commits, but the later ones are not necessarily fixes but\n can be enhancements, so you would need a way to tell which ones are\n \"fixing commits\" and which ones are not. You may want to use project\n specific hints to help you doing this:\n\n - a log that matches /This(?: commit) fixes/ is likely to be a fix;\n\n - a commit that touches the same vicinity of another commit after a\n short interval is likely to be a fix;\n\n - a commit that is made on 'maint' branch by definition is a fix;\n\n - a commit that changes test_expect_failure to test_expect_success have\n a high probability that it itself is a fix, or it comes soon after a\n fix;\n\n Once you have \"these are buggy commits, these are fixes\" in place, the\n remaining would be \"enhancements\" and you can do interesting things.\n\n * For the integrator, can you spot a pattern like \"what he accepts\n during weekdays tend to be buggier than what he applies during\n weekends\"?\n\n * For each contributor, can you spot a pattern like \"his late night\n commits are buggier than his early morning commits\"?\n\n * Can you spot a pattern like \"his changes to this area tends to be\n buggy but to that area tends to be very good\"?\n\n * Who tends to introduce more bugs, who tends to do more fixes than\n enhancements?\n\n * Is their correlation between being a day-job contributor and being\n more fixer than bug-introducer?\n"},{"id":"72755","messageId":"bd6139dc0803230707w29e31d89kf65cf4ac7ad3c8@mail.gmail.com","threadId":"12789","inReplyTo":"7v3aqik0nz.fsf@gitster.siamese.dyndns.org","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"alturin marlinon","fromEmail":"alturin@gmail.com","sentAt":"2008-03-23T14:07:58Z","receivedAt":"2008-03-23T14:07:58Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Sat, Mar 22, 2008 at 8:40 PM, Junio C Hamano wrote:\n> * Figure out which blocs of lines (not necessarily the whole files) relate\n> to each other by noticing that they are often modified in the same\n> commit.\n\nI've worked with directed graphs before (including writing my own\nimplementation) and have written an algorithm to detect cycles in a\ngraph.\nI think that this could be done by creating an undirected weighted\ngraph of all files in a commit.\nIf we create a graph that records how many time two files are edited\nin the same commit, the connection with the highest value would\nindicate that two files are strongly related.\nI'm not sure how this could be extrapolated to a section-based\napproach but a solution to that problem will have to be written\nanyway.\n(As with the other featires I'll need to be able to keep track of\nlines, the mechanism to be developed for that can be used here also.)\n\n> * Who are early birds and who are late night owls? Who are day-job\n> contributors and who are weekenders?\n\nSounds like a 'fun feature', but how about timezones?\nI'm not sure how commit times are recorded, in UTC, if so, does it\nalso record their timezone?\n\n> * Identify \"buggy commits\" from history, without testing. Zeroth order\n> approximation is that the lines it introduced were later rewritten by\n> other later commits, but the later ones are not necessarily fixes but\n> can be enhancements, so you would need a way to tell which ones are\n> \"fixing commits\" and which ones are not. You may want to use project\n> specific hints to help you doing this:\n\nA feature like this would fit well with the other \"buggy\ncommit/maintainer detection\" but would require a lot of customization.\nHowever, considering git already comes with a good customization\nsystem it should still be feasible.\n\n> - a log that matches /This(?: commit) fixes/ is likely to be a fix;\n\nPerhaps a regexp could be configured that marks a commit message as being a fix?\n\n> - a commit that touches the same vicinity of another commit after a\n> short interval is likely to be a fix;\n\nDo you mean with \"touches the same vicinity \" something like \"edits\ncode within 5 lines and within 5 commits of a commit x\"?\n\n> - a commit that is made on 'maint' branch by definition is a fix;\n\nEither a list of branches that are maintenance branches or a regexp\nwould be in place again I think.\n\n> - a commit that changes test_expect_failure to test_expect_success have\n> a high probability that it itself is a fix, or it comes soon after a fix;\n\nI'm not sure I understand this but that's probably because I'm not yet\nfamiliar with git's testing suite.\nDo you think a general rule to identify changes like this can be made?\n\n> * For the integrator, can you spot a pattern like \"what he accepts\n> during weekdays tend to be buggier than what he applies during\n> weekends\"?\n\nThat would be interesting data, I think a nice graph could be made\neasily, showing a column for weekdays (or one for each day) and a\ncolumn for weekends (or one for each day). Each column could then\nrepresent the amount of buggy commits / day, or perhaps the ration\nbuggy/enhancements. This histogram could then go back several weeks to\ngive a better picture.\nPerhaps a line style graph with two lines could be made, one for the\nweekends and one for the weekdays, or seven lines, one for each day.\nThat way it would be easy to track if the integrator is getting better\nat his job, or that he is perhaps having a bad/good period lately.\n\n> * For each contributor, can you spot a pattern like \"his late night\n> commits are buggier than his early morning commits\"?\n\nThis would be a 'fun feature' again I think, although it could of\ncourse be used to decide that 'late night commits' of this contributor\nshould be examined more carefully.\n\n> * Can you spot a pattern like \"his changes to this area tends to be\n> buggy but to that area tends to be very good\"?\n\nThis would require connecting commits to area's, that is, track what\narea's the buggy commits apply to. Maybe instead of tracking this on a\ncommit basis a per-file basis might be more interesting. That is,\ndon't just track if a commit is buggy, but also if a specific change\nto a certain file is buggy. Doing so would allow for more careful\ntracking of the area's a developer provides good work in.\n\n> * Who tends to introduce more bugs, who tends to do more fixes than\n> enhancements?\n\nThe former is an confronting yet interesting statistic, something that\ncould best be presented in a pie chart or such. The latter could be\nshown as a bar chart in which each bar is divided into three parts\n'buggy', 'fixes', and 'enhancements', with one bar per contributor.\n\n> * Is their correlation between being a day-job contributor and being\n> more fixer than bug-introducer?\n\nThis would require information about whether a contributor has a day\njob, although this might be inferred from the commit times feature\nmentioned earlier. It might be nice to have this feature to help\ndecide what kind of work to assign a contributor to (in the case that\ncontributors are assigned a task).\n\n\nThe question now though, is which of these features are feasible to do\nin one GSoC project? That is, which one should be done first, as I\nwant to finishing this feature even if I can't finish it all in three\nmonths. Should this be something that is decided in the application\nalready, or should I list all the features and then later on decide\n(with the aid of the community) which ones to implement first.\n\nThank you for your suggestions, this is starting to be very interesting indeed!\n\nSverre\n"},{"id":"72761","messageId":"alpine.LSU.1.00.0803231523110.4353@racer.site","threadId":"12789","inReplyTo":"bd6139dc0803230707w29e31d89kf65cf4ac7ad3c8@mail.gmail.com","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T14:28:52Z","receivedAt":"2008-03-23T14:28:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, alturin marlinon wrote:\n\n> On Sat, Mar 22, 2008 at 8:40 PM, Junio C Hamano wrote:\n> > * Figure out which blocs of lines (not necessarily the whole files) relate\n> > to each other by noticing that they are often modified in the same\n> > commit.\n> \n> I've worked with directed graphs before (including writing my own\n> implementation) and have written an algorithm to detect cycles in a\n> graph.\n> I think that this could be done by creating an undirected weighted\n> graph of all files in a commit.\n\nI think you will have to go to the line level to achieve what Junio \nsuggested.\n\n> > * Who are early birds and who are late night owls? Who are day-job\n> > contributors and who are weekenders?\n> \n> Sounds like a 'fun feature', but how about timezones?\n> I'm not sure how commit times are recorded, in UTC, if so, does it\n> also record their timezone?\n\nTimezones are recorded as epoch (seconds since Jan 1, 1970) and timezone. \nSo yes, you have that, _provided_ you trust the users to set up that thing \ncorrectly.\n\nI, for one, do not change the timezone on my laptop, just because I happen \nto be travelling through the air at high altitude...\n\n> > * Identify \"buggy commits\" from history, without testing. Zeroth order\n> > approximation is that the lines it introduced were later rewritten by\n> > other later commits, but the later ones are not necessarily fixes but\n> > can be enhancements, so you would need a way to tell which ones are\n> > \"fixing commits\" and which ones are not. You may want to use project\n> > specific hints to help you doing this:\n> \n> A feature like this would fit well with the other \"buggy\n> commit/maintainer detection\" but would require a lot of customization.\n> However, considering git already comes with a good customization\n> system it should still be feasible.\n\nYes. And it would be really interesting for me. Until it shows that I am \nthe biggest offender, of course.\n\n> > * For the integrator, can you spot a pattern like \"what he accepts\n> > during weekdays tend to be buggier than what he applies during\n> > weekends\"?\n> \n> That would be interesting data, I think a nice graph could be made\n> easily, showing a column for weekdays (or one for each day) and a\n> column for weekends (or one for each day). Each column could then\n> represent the amount of buggy commits / day, or perhaps the ration\n> buggy/enhancements. This histogram could then go back several weeks to\n> give a better picture.\n> Perhaps a line style graph with two lines could be made, one for the\n> weekends and one for the weekdays, or seven lines, one for each day.\n> That way it would be easy to track if the integrator is getting better\n> at his job, or that he is perhaps having a bad/good period lately.\n\nI think the bigger problem is not visualising it, but finding what is \nbuggy, and what not.\n\n> The question now though, is which of these features are feasible to do \n> in one GSoC project? That is, which one should be done first, as I want \n> to finishing this feature even if I can't finish it all in three months. \n> Should this be something that is decided in the application already, or \n> should I list all the features and then later on decide (with the aid of \n> the community) which ones to implement first.\n\nI think it can be vague about the order in which things will be \nimplemented. And the features which you think might be too complicated \nshould be marked as such: \"possible extension (which might not be finished \nwithin this project): \".\n\nCiao,\nDscho\n"},{"id":"72771","messageId":"bd6139dc0803230841l93cdd0do39bf6c35a5d732fa@mail.gmail.com","threadId":"12789","inReplyTo":"alpine.LSU.1.00.0803231523110.4353@racer.site","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"alturin marlinon","fromEmail":"alturin@gmail.com","sentAt":"2008-03-23T15:41:20Z","receivedAt":"2008-03-23T15:41:20Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Sun, Mar 23, 2008 at 3:28 PM, Johannes Schindelin\n wrote:\n> I think you will have to go to the line level to achieve what Junio\n> suggested.\n\nI'm not sure what you mean with \"go to the line level\"?\nDo you mean that using a Graph is not possible?\n\n> Timezones are recorded as epoch (seconds since Jan 1, 1970) and timezone.\n> So yes, you have that, _provided_ you trust the users to set up that thing\n> correctly.\n\nYeah, I'll trust the user on this ;).\nIf the timezone is stored as well this should be easy to do, sweet.\n\n\n> > > * Identify \"buggy commits\" from history, without testing. Zeroth order\n> >\n> > A feature like this would fit well with the other \"buggy\n> > commit/maintainer detection\" but would require a lot of customization.\n> > However, considering git already comes with a good customization\n> > system it should still be feasible.\n>\n> Yes. And it would be really interesting for me. Until it shows that I am\n> the biggest offender, of course.\n\nMaybe we can put in an if-check for user \"Johannes Schindelin\"? ;)\n\n> I think the bigger problem is not visualising it, but finding what is\n> buggy, and what not.\n\nYes, ofcourse, I think I'll be busy mostly following lines across\ncommits and after that determining if a commit is buggy or not.\n\n> I think it can be vague about the order in which things will be\n> implemented. And the features which you think might be too complicated\n> should be marked as such: \"possible extension (which might not be finished\n> within this project): \".\n\nCool, I think I can start on a RC for my application then! (Maybe I\nshould'of tracked it with git, then I could tag it...)\n\nThanks for the feedback, I really want to come up with a superb application!\n\nSverre\n"},{"id":"72776","messageId":"alpine.LSU.1.00.0803231729150.4353@racer.site","threadId":"12789","inReplyTo":"bd6139dc0803230841l93cdd0do39bf6c35a5d732fa@mail.gmail.com","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-23T16:32:31Z","receivedAt":"2008-03-23T16:32:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 23 Mar 2008, alturin marlinon wrote:\n\n> On Sun, Mar 23, 2008 at 3:28 PM, Johannes Schindelin\n> wrote:\n> > I think you will have to go to the line level to achieve what Junio \n> > suggested.\n> \n> I'm not sure what you mean with \"go to the line level\"? Do you mean that \n> using a Graph is not possible?\n\nIIUC you suggested having a graph of the files. But I think you have to \nhave a graph of file _parts_, i.e.\n\n\tgit.c:111-137\n\nwhich you can split even further should the need arise.\n\n> > > > * Identify \"buggy commits\" from history, without testing. \n> > > > Zeroth order\n> > >\n> > > A feature like this would fit well with the other \"buggy \n> > > commit/maintainer detection\" but would require a lot of \n> > > customization. However, considering git already comes with a good \n> > > customization system it should still be feasible.\n> >\n> > Yes. And it would be really interesting for me. Until it shows that \n> > I am the biggest offender, of course.\n> \n> Maybe we can put in an if-check for user \"Johannes Schindelin\"? ;)\n\nI thought about something like this, actually ;-)\n\n> > I think the bigger problem is not visualising it, but finding what is \n> > buggy, and what not.\n> \n> Yes, ofcourse, I think I'll be busy mostly following lines across \n> commits and after that determining if a commit is buggy or not.\n\nBut as Junio said, there are improvements, and even in the same commit \nseries, you can touch the same _line_ multiple times, to make the patch \nmore obvious.\n\nSee for example Linus' nice commit series regarding core.ignorecase. \nVery nicely done, very easy to understand, no buggy code.\n\n> > I think it can be vague about the order in which things will be \n> > implemented. And the features which you think might be too \n> > complicated should be marked as such: \"possible extension (which \n> > might not be finished within this project): \".\n> \n> Cool, I think I can start on a RC for my application then! (Maybe I \n> should'of tracked it with git, then I could tag it...)\n\nHehe. You'll come around putting even your photo collection into git, \nlike I do.\n\nCiao,\nDscho\n"},{"id":"72782","messageId":"7vzlsp73fs.fsf@gitster.siamese.dyndns.org","threadId":"12789","inReplyTo":"bd6139dc0803230707w29e31d89kf65cf4ac7ad3c8@mail.gmail.com","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-23T17:31:03Z","receivedAt":"2008-03-23T17:31:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"alturin marlinon\" writes:\n\n> On Sat, Mar 22, 2008 at 8:40 PM, Junio C Hamano wrote:\n> ...\n> The question now though, is which of these features are feasible to do\n> in one GSoC project? That is, which one should be done first, as I\n> want to finishing this feature even if I can't finish it all in three\n> months.\n\nHey, don't get me wrong. Please do not start your thought with \"which of\nthese features\". Proposed feature set should come from you. It's your\nproject after all.\n\nI was NOT giving you an instruction \"You should do all of these\" (I am not\nyour mentor), an opinion \"These are all important\" (I haven't thought\nthings through), nor criteria \"Unless you do your feature this way, you\nfail\" (I am not GSoC admin to judge your application nor evaluate at the\nend of project). Nothing of that sort. They are just random ideas, I\nhaven't even thought through the feasibility of, and/or possible approach\nto solution for, some of them.\n\nIf you find any of them interesting, you are welcome to include them in\nyour target feature set. Other uninteresting ones and unrealistic ones\nyou can discard without even commenting.\n"},{"id":"72814","messageId":"bd6139dc0803231432s4a1f9d86r7ec97847fa70ca82@mail.gmail.com","threadId":"12789","inReplyTo":"7vzlsp73fs.fsf@gitster.siamese.dyndns.org","subject":"Re: [SoC RFC] git statistics - information about commits","fromName":"alturin marlinon","fromEmail":"alturin@gmail.com","sentAt":"2008-03-23T21:32:57Z","receivedAt":"2008-03-23T21:32:57Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Sun, Mar 23, 2008 at 6:31 PM, Junio C Hamano wrote:\n> Hey, don't get me wrong. Please do not start your thought with \"which of\n> these features\". Proposed feature set should come from you. It's your\n> project after all.\n\nAh, perhaps I should have phrased it more like \"which of these\nfeatures are of most interest to the community\".\n\n> I was NOT giving you an instruction \"You should do all of these\" (I am not\n> your mentor), an opinion \"These are all important\" (I haven't thought\n> things through), nor criteria \"Unless you do your feature this way, you\n> fail\" (I am not GSoC admin to judge your application nor evaluate at the\n> end of project). Nothing of that sort. They are just random ideas, I\n> haven't even thought through the feasibility of, and/or possible approach\n> to solution for, some of them.\n\nEven so, most of them are very interesting, although I agree that the\nfeasibility should perhaps be looked at more closely.\n\n> If you find any of them interesting, you are welcome to include them in\n> your target feature set. Other uninteresting ones and unrealistic ones\n> you can discard without even commenting.\n\nI think I will divide the features into subsets and list the\ndependencies between them.\nThen based upon 'popularity' an easy selection could be made.\nJohannes said:\n\n> I think it can be vague about the order in which things will be\n> implemented. And the features which you think might be too complicated\n> should be marked as such: \"possible extension (which might not be finished\n> within this project): \".\n\nWould such a list be allowed to include such a list of grouped\nfeatures which then can be selected later on?\n"}]}