Re: [PATCH] Avoid errors from git-rev-parse in gitweb blame

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 3 Jan 2008, Luben Tuikov wrote:
> On Tue, 6/3/08, Rafael Garcia-Suarez <rgarciasuarez@gmail.com> wrote:
>> 2008/6/3 Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> I was thinking about extending git-blame porcelain format (and also
>>> incremental format, of course) by 'parents' (and perhaps
>>> 'original-parents') header...
>> 
>> OK, I see. That would be nice. Also: currently taking "$full_rev^"
>> directs the user to the parent commit, but it would be more
>> user-friendly to point at the previous commit where the selected file
>> was modified instead.
> 
> The intention was that it shouldn't necessarily be the (strict) parent
> of the change (changed segment), since it may or may not have changed
> in the strict parent commit.  The intention was that it
> "starts"/"opens" the parent commit so that "git" would start from
> there and find the actual change/commit where that line/segment has
> changed.  And it has worked pretty fine for me when data-mining
> (something I do quite often) code evolution.
> 
> My commit 244a70e608204a515c214a11c43f3ecf7642533a was really derived
> from a command line, which I had started to use quite often and had
> been "looking for" for quite some time.

Let us assume for a bit that history is linear, and looks like this:

    ...*---A---*---*---b---.---D^---D---*---x

where 'x' is starting point (revision we start running git-blame from),
'D' is revision given line is blamed on, 'D^' is parent of revision 'D',
'b' is previous commit in a given file history, and 'A' is previous 
commit which modifies given line of a given commit.

It means that the history looks like below
  $ git rev-list x
  [...]
  D
  D^
  .
  b
  [...]
while history of a given file looks like this
  $ git rev-list x -- file
  [...]
  D
  b
  [...]

Now for all commits in the b..D^ range (between D^ and b, including 
endpoints), given file has the same contents, and therefore 'blame' 
view would also look the same.  That is why it works.


The only problem I can see when blamed commit is merge commit; D^ means 
D^1, ehich mesna first parent.  Now, I think that merge commit might be 
blamed _only_ if it was "evil merge" (change/line didn't came from any 
of parents).  But this is quite rare situation; additionally the bug is 
not very visible; when clicking on link you would go to not correct 
view, but this not-correctness isn't obvious on the first glance.
-- 
Jakub Narebski
Poland