Re: [PATCH] [gitweb] Blame "linenr" link jumps to previous state at "orig_lineno"
- From
- Luben Tuikov <ltuikov@yahoo.com>
- Date
- Jan 5, 2007, 22:56 UTC
- Message-ID
- <46370.61489.qm@web31814.mail.mud.yahoo.com>
- In-Reply-To
- <7vk602jfo7.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
Show 21 quoted lines
> Luben Tuikov <ltuikov@yahoo.com> writes: > > > A quick show-and-tell of this patch is after applying it, open > > "blame" on a file, click on a linenr link of a block which > > has only a single line changed -- the diff between what > > you're seeing now and before is at least that line. This you can > > data-mine with gitweb back to where the line was introduced. Similar > > argument applies to blocks of more than one line. > > One non-question and one question: > > - This favors the first parent, which is obviously the right > thing for most of the time. I wonder what happens to a > merge, though, but I realize that a line attributed to a > merge is even rarer, and such a line is introduced by the > "evil merge". > > - I wonder if the line number is correct for the parent > commit. How well does this work when you clicked a line that > was added at the end of the file, where the $orig_lineno goes > beyond the whole file in the parent?
It displayed the whole file, since the previous state of the file I was looking at was short. In effect for the case in point it displays the bottom of the file.
If you remember, this had been my "white whale" for about a year and a half now. I accidentally "got it" while using git-blame from shell prompt.
I think it's a worthwhile thing to have in gitweb.
Luben