Subject: Re: [RFC] Use cases for 'git statistics'

From: Jakub Narebski <[email-masked]>
Date: Wed, 14 May 2008 22:34:54 +0200

On Tue, 13 May 2008, Sverre Rabbelier wrote:
> On Tue, May 13, 2008 at 3:07 PM, Jakub Narebski <[email-masked]> wrote:

[on helping maintainer decide how closely patch should be examined]

>>  Weighting different statistics, bayesian hypotesis/filtering, expert
>>  system, machine learning... I guess that would be quite a work to do
>>  it well.  Probably would require to calculate and adjust scoring of code
>>  (difficulity) and authors (skill), and matching them...
>>
>>  This is certainly in the "wishlist" scope.
> 
> Yeah, I think it would go in the 'c' of 'MoSCoW', but it could be very
> useful when done right.

Errr... what do you mean by 'MoSCoW'?

[here I think you cut a bit too much]
>>
>>  What I had in mind here, but didn't explain clear enough, was an
>>  extension to pickaxe search.  You want to find when current error
>>  message was created, even if the way of handling it (fprintf vs. die)
>>  changed, or if code was indented, or was moved.
> 
> I'm not familiar with pickaxe, what you suggest sounds like grepping
> the content also throughout history?

Documentation/glossary.txt (linked from git(7), in "Git User's Manual")

   pickaxe::
        The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore
        routines that help select changes that add or delete a given text
        string. With the `--pickaxe-all` option, it can be used to view the full
        <<def_changeset,changeset>> that introduced or removed, say, a
        particular line of text. See linkgit:git-diff[1].

git-diff(1):

       -S<string>
              Look for differences that contain the change in <string>.

       --pickaxe-all
              When -S finds a change, show all the changes in that changeset, not
              just the files that contain the change in <string>.

       --pickaxe-regex
              Make the <string> not a plain string but an extended POSIX regex to
              match.

>>  Or find all error messages, in the order they were created, for example
>>  in git case to find ancient error messages and replace it by something
>>  more user-friendly (or less selective about choosing friends ;-).
> 
> I understand what you want, a search for specific content, from old to
> new, stopping when you have a match?

But let me elaborate a bit. What I wanted in my example is for each
die("<message>") and error("<message>") to have commit and date where
<message> was introduced (even if it was in fprintf(stderr, ...) then).

>>  Seriously, what I had in mind was to integrate author dates and commit
>>  dates into project management system scheduling.
> 
> I'm not sure what gain that would bring though, as it can only provide
> end dates, not 'starting work now' timestamps...

Well, if you use patch management system such like StGit, it could
trace when patch was created, when was refreshed, when was temporarily
abandoned (push, pop, float, new), ans when was finalized (commit or
clean).

But that is also in the realm of vague ideas, not concrete applications.
-- 
Jakub Narebski
Poland