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

From: Sverre Rabbelier <alturin@gmail.com>
Date: Jul 12, 2008, 07:39 UTC
Message-ID: <bd6139dc0807120039q5e5a31a3xc9f23cb05e2435a5@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0807120028280.8950@racer>

On Sat, Jul 12, 2008 at 1:33 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> If you were suspecting that I would write the patch once the semantics are
> finalized, you would be absolutely correct.

Awesome!

Show 6 quoted lines

>> Mhhh, such would be beyond the scope of implementing manually indeed,
>> and should be left to the likes of a diff tool instead in order to
>> prevent reinventing the wheel :).
>
> That is why I was suggesting using the diff tool with munged input to find
> out what works best.

This makes sense, put the responsibility where it belongs, that way someone else may use it as well.

> When that is done, I'll turn it into C.

Very much appreciated. I will start playing around with munged diffs today and keep you posted of the result.

Show 6 quoted lines

>> Correct, that's because that is what 'git log' tells me.
>
> I suspect that one big "git log" will not tell you enough.  You probably
> need to make your tool aware (at least a little) about merges, just as you
> probably made it aware about parent/child relationships (to track the
> changes along renames)...

Atm it is not aware of parent/child relationships in the activity analysis. (This is not the case in the 'branch contains' metric, in which I use 'git rev-list --parents' to extract and analyse that.) I thought of tracking renames by honoring what "git log -C -C -M" tells me (e.g., whenever it says {foo/bar.c => bar.c} I move all the metrics under key "foo/bar.c" to "bar.c").

-- 
Cheers,

Sverre Rabbelier