Kevin Bracey <kevin@xxxxxxxxx> writes: > I agree that this is the controversial patch of the two. It's going to > chuck away 3-4 years of what Git users are used to, albeit in favour > of a decade of what Perforce users are used to. And it also makes it > inconsistent with all the other mergetools (at least assuming their > display matches their command line). If p4merge GUI labels one side clearly as "theirs" and the other "ours", and the way we feed the inputs to it makes the side that is actually "ours" appear in p4merge GUI labelled as "theirs", then I do not think backward compatibility argument does not hold water. It is just correcting a longstanding 3-4 year old bug in a tool that nobody noticed. For people who are very used to the way p4merge shows the merged contents by theirs-base-yours order in side-by-side view, I do not think it is unreasonable to introduce the "mergetool.$name.reverse" configuration variable and teach the mergetool frontend to pay attention to it. That will allow them to see their merge in reverse order even when they are using a backend other than p4merge. With such a mechanism in place, by default, we can just declare that mergetool.p4merge.reverse is "true" when unset, while making mergetool.$name.reverse for all the other tools default to "false". People who are already used to the way our p4merge integration works can set mergetool.p4merge.reverse to "false" explicitly to retain the historical behaviour that you are declaring "buggy" with such a change. How does that sound? David? -- 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