Re: [RFC v2] blame: new option --prefer-first to better handle merged cherry-picks

"Bernhard R. Link" [off-list ref] writes:

* Junio C Hamano [off-list ref] [140113 23:31]:

quoted

I read the updated documentation three times but it still does not
answer any of my questions I had in $gmane/239888, the most
important part of which was:

    Yeah, the cherry-picked one will introduce the same change as
    the one that was cherry-picked, so if you look at the end result
    and ask "where did _this_ line come from?", there are two
    equally plausible candidates, as "blame" output can give only
    one answer to each line.  I still do not see why the one that is
    picked with the new option is better.

Because:
  - it will blame the modifications of merged cherry-picked commit
    to only one commit. Without the option parts of the modification
    will be reported as coming from the one, parts will be reported
    to be from the other. With the option only one of those two commits
    is reported as the origin at the same time and not both.
  - it is more predictable which commit is blamed, so if one is
    interested in where some commit was introduced first into a
    "mainline", one gets this information, and not somtimes a different
    one due to unrelated reasons.

quoted

To put it another way, why/when would an end user choose to use this
option?  If the result of using this option is always better than
without, why/when would an end user choose not to use this option?

While the result is more consistent and more predictable in the case
of merged cherry picks, it is also slower in every case.

Consistent and predictable, perhaps, but I am not sure "exact" would
be a good word.

Wouldn't the result depend on which way the cherry pick went, and
then the later merge went?  In the particular topology you depicted
in the log message, the end result may happen to point at the same
commit for these two paths, but I am not sure how the change
guarantees that "we always point at the same original commit not the
cherry-picked one", which was implied by the log message, if your
cherry-pick and merge went in different direction in similar
topologies.

And that is why I said:

    At best, it looks to me that it is saying "running with this
    option may (or may not) give a different answer, so run the
    command with and without it and see which one you like"

With the stress on "different" answer; it the change were "with the
option the result is always better, albeit you will have to wait
longer", I would not have this much trouble accepting the change,
though.