Jeff King <peff@xxxxxxxx> writes: > When showing a combined diff, we are comparing two (or more) > parents to a final state, and some of these states may be > the same. Here's a table of the possible contents for a > given path (for two parents, but we will generalize to more > in a moment; we also omit isomorphic cases where the parents > are swapped): > > case | M | P1 | P2 > ------------------- > 1 | A | A | A > 2 | A | A | B > 3 | A | B | B > 4 | A | B | C > > In case 1, the path was not relevant to the merge at all, > and we omit it as uninteresting. In case 2, we did resolve > the path, but in favor of one side. We also consider this > uninteresting and do not show the diff. > > In case 4, we had a real content-level merge, and the > combined diff is interesting. We show it. > > That leaves case 3, in which both parents are the same, but > the merge picks a new content. This should be rare in > normal merges, though it could happen if you updated an > unrelated file due to a resolution elsewhere (i.e., an evil > merge that crosses a file boundary). But it happens > frequently in the fake merge commits we create for stashes, > in which one parent is the base of the stash and the other > is the index (in which case it simply means that the index > entry for the path was not touched). > > Right now, we treat it the same as case 4, and show a normal > combined diff. However, the result is harder to read, and > the combined nature of the diff gives no extra information; > every marker in the combined diff will be identical for both > parents. > > This patch adds a new option, "--simplify-combined-diff", > which converts this case into a normal, non-combined diff. > It would not be correct to simply omit it, because there > really is an interesting change going from B..A. It's just > that there are not two interesting changes, which the > combined diff would show. > > When generalizing this to more than two parents, we have two > options: > > 1. Either simply to a single parent content, or not at all. > > 2. Omit parents whose contents are duplicates of other > parents. > > For a case like "A B B C", option (2) would still result in > a combined diff, but one with fewer sources. However, it > would also be ambiguous. The parents in a combined diff are > marked only by their position, so omitting a position means > that a reader can no longer tell which line goes with which > parent. > > Instead, we choose option (1). Either you get the full > combined diff, or you get a normal non-combined diff. Very nicely analyzed. The changes to the code looked also good from a cursory read. Thanks. -- 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