Sergey Organov <sorganov@xxxxxxxxx> writes: >> But I do think that it is an utterly misleading option to show >> merges in general. When "log" is used with the "--first-parent" >> traversal, "compare with the first parent to show everything the >> side branch did" is an acceptable alternative, but even there, it is >> far less suitable than the "remerge" or "cc", I would think, as the >> default format. > > What I still fail to see is why somebody wants to mix traversal rules > with representation of merge commits, sorry. It is not about "mixing". What I meant was that diff between the pre-merge state and the merge result as two-tree comparison may be an acceptable view of "what did this _merge_ contribute to the history" and that is in line is what the first-parent traversal is trying to show the reader of the history, which is "this merge contributed to the history, and then this other merge contributed to the history, ...". It also may make sense when one is inspecting a merge in isolation, i.e. "git show M". When one is viewing individual commits without omitting commits on the side branch, however, showing "what did the side branch as a whole contributed to the history at this merge" makes little sense and is misleading. Such a patch given for a merge mostly overlaps with what the reader sees immediately after seeing the merge (i.e. the commits on the side branch, with their own patches, each of which has already been shown in the first-parent comparison of the merge). In other words, "git log --no-first-parent" is about contribution of each single commit (whether it is a merge or a non-merge) makes, and the --diff-merges=1 presentation is not in line with that worldview, in which the contribution to the history the merge alone makes is what --cc or remerge tries to show, i.e. "what did the merge do, on top of what the commits on the side branch contributed to the history?" So, it is not like two unrelated things are mixed together. It is more like showing the result of a merge as a diff relative to its first-parent is tied to and consistent with the viewpoint of history as single strand of pearls that is a series of merges into the first-parent chain, but not with non-first-parent presentation of the history.
