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

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 3, 2008, 21:31 UTC
Message-ID: <200806032331.44514.jnareb@gmail.com>
In-Reply-To: <940824.46903.qm@web31808.mail.mud.yahoo.com>

On Tue, 3 Jan 2008, Luben Tuikov wrote:

Show 23 quoted lines

> 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