Max Kirillov <m...@max630.net> writes:
> 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 <m...@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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
