From: Luben Tuikov <ltuikov@yahoo.com>
Date: Fri, 05 Jan 2007 22:56:16 GMT
Subject: Re: [PATCH] [gitweb] Blame "linenr" link jumps to previous state at "orig_lineno"
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:
> 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