On Fri, 23 Jan 2009, Tim Jenness wrote:
> % git log --diff-filter=A --pretty=short -- err1Rep.c
> commit a60aa65f9b51
> % git blame -C -C a60aa65f9^! -- err1Rep.c
> [this tells me that 90% of the lines came from errRep.c]
> % git log --diff-filter=A --pretty=short -- errRep.c
> commit eda910d62bef8f8e
> % git blame -C -C eda910d^! -- errRep.c
> [this tells me that 90% of the lines came from err_rep.f]
> % git log --diff-filter=A --pretty=short -- err_rep.f
> commit 1104b43d28fb
> % git blame -C -C 1104b43d28f^! -- err_rep.f
> [95% err_rep.f so no parent]
>
> which is obviously scriptable and allows you to run git-log to get the full
> log output. The downside is that this took my computer about 3 minutes to
> actually tell me that err1Rep.c is derived from err_rep.f. That's because
> it's comparing that code with the entire repository. It even tells me that it
> thinks that the SAE_PAR and IMPLICIT NONE lines come from libkappa/copybad.f
Even apart from the slowness this is not behaviour I much like the
sound of - it seems to be trying to be far too clever. If I want to
track history over renames I'd like it to cope with rewrites as well.
I want to tell the VCS what the history is, not the other way around.
If I do an svn copy or svn mv I'm doing it to tell the system that
this is history I want to be preserved - otherwise I'd just do a cp/mv.
Getting a bit more paranoid I also see a danger of it giving you
an incentive to write code to help out the code matching - e.g. avoid
changing or deleting comments to preserve (git-perceived) history,
or using different variable names in files with similar structure
that you don't want to be identified as the same as something else.
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|