On Tue, May 11, 2021 at 12:46 PM Sergey Organov <sorganov@xxxxxxxxx> wrote: > > Alex Henrie <alexhenrie24@xxxxxxxxx> writes: > > > On Tue, May 11, 2021 at 8:03 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > >> > >> Junio C Hamano <gitster@xxxxxxxxx> writes: > >> > >> > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> > >> [...] > >> > >> > If we enable "some kind of diff" for "-m", I actually think that by > >> > default "git log -m" should be turned into "log --cc". As you told > >> > Alex in your response, "log -m -p" is a quite unpleasant format to > >> > read---it is there only because it was the only thing we had before > >> > we invented "-c/--cc". > >> > >> Please, no! --cc has unfortunate feature of outputting exactly nothing > >> for a lot of merge commits, causing even more confusion than historical > >> "-m -p" format. > >> > >> The best default for -m output is --diff-merges=first-parent. Everybody > >> is familiar with it, and it's useful. > >> > >> > But that might be outside the scope of this series. I dunno, but if > >> > there is no other constraints (like backward compatibility issues), > >> > I have a moderately strong preference to use "--cc" over "-m -p" > >> > from the get go for unconfigured people, rather than forcing > >> > everybody to configure > >> > >> I rather have strong preference for --diff-merges=first-parent. --cc is > >> only suitable for Git experts, and they know how to get what they want > >> anyway. Yep, by using --cc. Why spare yet another short option for that? > >> > >> Overall, let's rather make -m give diff to the first parent by default. > >> Simple. Useful. Not confusing. > > > > Honestly --diff-merges=separate is fine. Two weeks ago, when I started > > this discussion, I was trying to use `git log -m` and `git show -m` to > > find which merge commit introduced a particular change. Extremely > > verbose diff output would have been great for that, the confusing part > > was just that `git show -m` produced diff output and `git log -m` did > > not. > > This is not a case in favor of "separate" over "first-parent" as the > default for "-m", right? > > "Which merge commit introduced particular change" is exactly what > --diff-merges=1 achieves, so "--diff-merges=separate" was not in fact > needed, as I see it. Moreover, it could have produced wrong positives. > Looks like --diff-merges=1 is a better fit. I didn't know which branch the change came from. If the change came from the first branch, it would not have appeared under the merge commit with --diff-merges=first-parent. But the change would definitely appear with --diff-merges=separate, which enabled me to identify the merge commit that included it. So yes, this is a case in favor of "separate" over "first-parent", but it's probably not a common enough scenario to demand keeping "separate" for -m. On Tue, May 11, 2021 at 12:31 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > Interesting. I have a strong preference for --diff-merges=remerge > (yeah, I know it's not upstream, but it's been ready to submit for > months, but just backed up behind the other ort changes. Sorry, I > can't push those through any faster). I've had others using it for > about 9 months now. --diff-merges=remerge is the default I would expect when no options have been configured or passed on the command line (although it would not have helped in the scenario I described above). I look forward to using it! -Alex
