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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Bernhard R. Link" <brl+git@xxxxxxxxxxxxxx> writes:

> When giving git-blame the new option introduced with my patch, only
> the order of parents determines which commit is blamed. Without
> the option (i.e. the currently only possible behaviour) which commit
> is blamed depends what else touches other parts of the file.

I am trying to figure out why that difference matters, in other
words, when using the new option is actually useful.  You give the
command a scenario that can be solved in two equally valid ways
(blaming to either A or A' is equally valid), and sometimes the
command gives the identical result with or without the new option,
and some other times the user gets a different but an equally valid
result (but after traversing more history spending more cycles).  I
am not sure what problem the new option solves.  I am trying to come
up with an easy-to-understand explanation to the end users: "If you
want to see blame's result with the property X, use this option---it
may have to spend extra cycles, but the property X is so desirable
that it may be worth it".  And I am having a hard time understanding
what that X is.

> But in the example with one commit B touching also b and one commit C
> touching also c, there is (without the new option) always one part
> of the cherry-picked commit is blamed on the original and one on the
> cherry-picked, no matter how you order the parents.

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.  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", which does
not sound too useful to the end users.  That is where my confusion
comes from.

> (While by having your mainline always the most leftward parent, with
> the the new option you always get those commit blamed that is the
> "first one this was introduced to mainline".)

Yes, I vaguely recall we talked about adding --first-parent option
to the command in the past.  I do not remember what came out of that
discussion.

--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]