Re: [PATCH v4 1/3] Add test to describe expectation of blame --reverse with branched history

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 26, 2015, 06:27 UTC
Message-ID: <xmqqeggijga3.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1445837217-4252-3-git-send-email-max@max630.net>

Max Kirillov <max@max630.net> writes:

Show 13 quoted lines

> If history contains merges from feature branches, `blame --reverse`
> reports not the commit when the line was actually edited, but head of
> the last merged branch which was created before the edit.
>
> As a workaround, `blame --reverse --first-parent` could be used to find
> the merge of branch containing the edit, but it was disabled in
> 95a4fb0eac, because incorrectly specified range could produce in
> unexpected and meaningless result.
>
> Add tests which describe ideal functionality with and without
> `--first-parent`.
>
> Signed-off-by: Max Kirillov <max@max630.net>

I _think_ I know why it would be useful to allow "--first-parent" to the command; it is useful the same way why "git log --first-parent $path" would be a good way to get an overview.

But I am puzzled by your complaints (I'd characterise the statement as such, given your second paragraph calls the combination a "workaround") in the first paragraph. I honestly do not understand where it comes from at all.

The reverse blame begins from an old state and shows the most recent child in the history that each line survived to, and it does not show what commit removed the line from the original state. And that does not have anything to do with the presence of any merges or forks in the history. The command will always report "not the commit that edited the line." There is nothing special about "If the history contains merges".

If you have this history, for example:

    D---E---F
   /         \*
  O           X---Y
   \         /
    A---B---C

where O had the original file, which was not touched by any commits on the branch on the upper side, and commit B rewrote all lines of the file, running blame in reverse may show A as the last point where all lines survived up to, if the "reversed" history happened to consider A as the earlier "parent" (in reality it is a child but blame is about assigning blame for each line from child to parents so in the reversed history, real children becomes parents). Or it may show F as the last point where all lines survived up to, if D was picked as the earlier "parent". Because there is no inherent ordering between A and D, both of which are children of O, your result is not necessarily "head of the last merged branch".

But I do not see how "first-parent" would be a workaround for that. The option would be useful to force the assignment of blame (in reverse) along the first-parent chain O---D---E---F---X---Y so that you can get a bird's-eye view of the history, i.e. squashing all that happened in A---B---C as if that happened at X.

The explanation of the first paragraph needs to be rewritten to make it understandable, but I am not sure what relevance it has with this change.

Thanks.