On Fri, Feb 06, 2009 at 11:10:23PM +0100, Jonas Fonseca wrote:
> > It looks like you just keep the view on the same line number when moving
> > to the new blame output. In practice, this has very mixed results. Most
> > of the time it does exactly what I want, but if the file changes
> > significantly, you get dumped at a totally unrelated part of the file.
> > I'm not sure if there is a more clever solution, though.
>
> Yes, it is a bit easy to get lost. It should be possible to find the
> original line number either by making git-blame also honor
> --show-number for the --incremental output or by using the "porcelain"
> version:
>
> git blame --show-number -L <line>,<line> <rev> <file>
I'm not sure that will always work. You know that in some version of the
file, line number X is of interest to you. You want to find the "same"
spot in the parent commit. So you can:
1. use the line number in the blamed file; this doesn't work because
the re-blamed file may have much more or less content before X,
which is going to shift the content of interest.
2. use the line number that the content was introduced on in the blamed
commit. This has the same problem as above, but may be more
accurate because you are only jumping _one_ revision to the parent
of the blamed commit (instead of from wherever you started
blaming).
My impression is that tig is currently doing (1). I think (2) will
suffer from the same problem, but in practice the margin of error will
be much smaller because your are rewinding through fewer changes. So if
that is what you were suggesting, I think it is probably worth trying.
It would require a "reload and jump to this arbitrary line" function,
which I remember being problematic when I did my original patch a long
time ago. But I haven't looked at the new code to see if it is easier
now (it looks like you have been doing quite a bit of refactoring in
that area lately).
You could also try matching up content, but that is equally error-prone.
You can't find the same line in the parent, for the obvious reason that
you've just blamed it, so by definition it doesn't exist in the parent.
You could try doing a fuzzy match on the surrounding blamed lines, but
there is no guarantee that they exist in the parent commit, either. So I
think the line number guess is probably our best bet.
-Peff
--
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
