On Tue, 3 Jan 2008, Luben Tuikov wrote:
> On Tue, 6/3/08, Rafael Garcia-Suarez <rgarciasuarez@xxxxxxxxx> wrote:
>> 2008/6/3 Jakub Narebski <jnareb@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
