Re: [ANNOUNCE] tig-0.14
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 7, 2009, 07:28 UTC
- Message-ID
- <7vprhuzoxm.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <20090207071056.GB14856@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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 has been quite a while since I did the "show previous" feature of "git-blame --porcelain" that has been forever queued in 'next'; if I remember correctly, it implemented (2).
The reason why it never graduated from 'next' is exactly this issue. By definition, there is no "previous" line number (if there were such a thing that says "This line was at line N in the parent of the blamed commit", then the commit wouldn't have taken the blame but would have passed it down to the parent), and we need to come up with a reasonable heuristics.
So perhaps this discussion would motivate somebody to finish that part off, and tig and other Porcelains can just read the necessary line number from the git-blame output.