Junio C Hamano <gitster@xxxxxxxxx> writes: > Elijah Newren <newren@xxxxxxxxx> writes: > >> On Tue, May 11, 2021 at 7:03 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: >>> ... >> I think --cc is a lot better than -m for helping you find what users >> changed when they did the merge, but I agree the format is somewhat >> difficult for many users to understand. (--diff-merges=remerge, or >> --remerge-diff, fixes these problems, IMO.) I think >> --diff-merges=first-parent, while fine when explicitly requested on >> the command line, would be wildly misleading as a default because it >> would attribute changes to a merge commit that were made elsewhere. >> >>> Overall, let's rather make -m give diff to the first parent by default. >>> Simple. Useful. Not confusing. >> >> I think it's confusing. > > I do not think it is particularly confusing---after all, it shows > "here is a comparison between two trees" the users are familiar with > in a single strand of pearls. Moreover, it's comparison between two most natural trees, the same trees as for non-merge commits. > > 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. If I want to see merges in --cc, I want them in --cc, no matter which way I get to particular commit through the DAG. If I want to see them in --diff-merges=1, I want them this way, no matter how I happened to get to particular commit. Is it more likely that I want to see merges in --diff-merges=1 when I use --first-parent? Yes, of course! That's why --first-parent implies --diff-merges=1. Vice versa? No, why? Thanks, -- Sergey Organov
