Re: [GitStats] Bling bling or some statistics on the git.git repository

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 11, 2008, 22:07 UTC
Message-ID: <alpine.DEB.1.00.0807112257450.8950@racer>
In-Reply-To: <bd6139dc0807111452x778759d4jd6ac71338974018e@mail.gmail.com>

Hi,

On Fri, 11 Jul 2008, Sverre Rabbelier wrote:

Show 12 quoted lines

> On Fri, Jul 11, 2008 at 11:22 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Fri, 11 Jul 2008, Sverre Rabbelier wrote:
> >
> > I think quite a lot of our changes do code moves; this should be 
> > accounted for differently.
> 
> Yeah, I wish 'git log -C -C -M --numstat --sacrifice-chicken 
> --pretty=format:%ae --' would take care of that... That is, a git-blame 
> like mechanism that would detect such moves on a per-commit basis and 
> report them would be very useful to me.

Well, the chicken (or better, a goat) should be sacrificed by you... The option I would call "--code-moves".

But the semantics of that need to be sorted out in a shell script first; maybe like I outlined (if that was not coherent, please say so).

Show 7 quoted lines

> >> For some reason you people can't seem to make up your mind about a 
> >> file that's not even 1500 lines in size ;).
> >
> > Heh.  We might need to change it once or twice, in the future.
> 
> *chuckles*, I'm curious why the Makefile is such a hard file to get 
> right :).

Well, it is not a matter of getting it right, but it is a matter of changes. For example, everytime we move code from one program into the library, and create a file for that, code changes.

Everytime we realize that we need to set some special settings for a platform, the Makefile needs to be changed.

Everytime a shell script is added, or converted to a builtin, the Makefile needs to be changed.

We are lucky that our maintainer is such a good shell hacker, otherwise every version number change, you guessed it, would need the Makefile to be changed.

Show 13 quoted lines

> >> A note is in order here, this data was mined with "git log 
> >> --num-stat" so things like moving files and copying files are not 
> >> accounted for.
> >
> > In my opinion it would be even more interesting to see code moves 
> > (i.e. not whole files).  For example, we moved some stuff from 
> > builtins into the library.  The real change here is not in the lines 
> > added and deleted.
> 
> Very much so, but the former I figure can be easily done with 'git log
> -C -C -M' I discovered (I need to parse it's output though, and also
> determine what to do with moves statistics wise. Should changes made
> due to moves just be ignored?)

That is not very interesting, as we often move so small parts (think "one function") that -C -C -M does not trigger.

Show 18 quoted lines

> >> I thought about using git-blame to gather this info before, but it is 
> >> not the right tool for the job. If anyone else has any idea's on what 
> >> would be better please let me know and I'll happily dig into it :).
> >
> > I think that you need to analyze the diff directly.  One possible (quick
> > 'n dirty) way would be to cut out long consecutive "+" parts of the hunks,
> > replace the "-" by "+", and use "git diff --no-index" to do the hard part
> > of searching for that code in the "-" part of the original diff.
> 
> That sounds interesting, I won't need to actually do that though, I
> already have a diff parser that gives me the lines added VS lines
> deleted on a hunk-by-hunk basis. If it is a true move (e.g., code
> removed in file X and added in file Y) it should be trivial to detect
> that.
> Something along the lines of:
> for hunk in added:
>   if hunk in deleted:
>     print("Over here!!")

I think that is not enough, as a code move can mean that part of a function was refactored into a function. The consequence is often a reindent, and possibly rewrapping.

And it can mean that some lines have to be inserted here and there. I still would count that as a code move "with touch-ups".

So I'd like to see something like

<number-of-commits>: <lines-added> <lines-removed> \
	<lines-moved-from> <lines-moved-to> <filename>

BTW I realized something else: your http://alturin.googlepages.com/full_activity.txt lists only "gitk-git/po/es.po" under git-git/po/. And it has as many added as deleted lines.

So I suspect that "po/*" really lists both gitk's as well as git-gui's .po files, but merged together.

Ciao, Dscho