"Bernhard R. Link" <brl+...@mail.brlink.eu> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
