On Sat, Jul 12, 2008 at 1:33 AM, Johannes Schindelin
<Johannes.Schindelin@xxxxxx> wrote:
> If you were suspecting that I would write the patch once the semantics are
> finalized, you would be absolutely correct.
Awesome!
>> 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.
>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
