Hi,
On Sat, 12 Jul 2008, Sverre Rabbelier wrote:
> On Sat, Jul 12, 2008 at 12:07 AM, Johannes Schindelin
> <Johannes.Schindelin@xxxxxx> wrote:
> >> On Fri, Jul 11, 2008 at 11:22 PM, Johannes Schindelin 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".
>
> If you suggest I write up a patch to 'git log' I am afraid that would
> require quite a bit more skill && knowledge of 'git log' than I have
> (which is about Null :P).
If you were suspecting that I would write the patch once the semantics are
finalized, you would be absolutely correct.
> > 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).
>
> Python is one big shell script :P, so if you meant that it should be
> part of GitStats (instead of part of 'git log', which I commented on
> above), python would be just fine :). The concept was clear enough
> though, I think I understand what you mean.
Fair enough. As long as you use a language that is easy to prototype
quickly and dirtily in. Such as Python.
> >> 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.
>
> Right, why aim for the stuff when there's much more interesting fun out
> there? If there was a --code-moves I agree with you that it would be a
> lot more interesting to have than going with the current approach and
> throwing in '-C -C -M'.
Let's go for it, then!
> >> 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.
>
> 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.
When that is done, I'll turn it into C.
> > 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.
>
> 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)...
Ciao,
Dscho
--
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
