From: david@lang.hm Date: Sat, 07 Feb 2009 08:55:18 GMT Subject: Re: [ANNOUNCE] tig-0.14 Message-ID: In-Reply-To: <7vprhuzoxm.fsf@gitster.siamese.dyndns.org> On Fri, 6 Feb 2009, Junio C Hamano wrote: > Jeff King 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. this sounds like the same basic problem I was having around the begninning of the year (thread subject 'how to track the history of a line in a file') what I ended up doing was to use git blame to go back and find the commit where a line was introduced, then use git diff to find the changes, then find the hunk of the diff that introduced the line, then find the lines that were removed and trace them back (repeating the process) David Lang