Re: [PATCH 6/6] diff-merges: let -m imply -p

[Sergey Organov <sorganov@gmail.com>]

Elijah Newren <newren@gmail.com> writes:

> On Tue, May 11, 2021 at 12:00 PM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> Elijah Newren <newren@gmail.com> writes:
>>
>> > On Tue, May 11, 2021 at 7:03 AM Sergey Organov <sorganov@gmail.com> wrote:
>> >>
>> >> Junio C Hamano <gitster@pobox.com> writes:
>> >>
>> >> > Junio C Hamano <gitster@pobox.com> 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?
>> >
>> > 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.
>>
>> Once somebody uses it for 9 months and starts to understand what it is
>> and really loves it, she can still set log.diffMerges=remerge (new
>> feature) and have fun.
>>
>> >
>> > I think --cc is a lot better than -m for helping you find what users
>> > changed when they did the merge,
>>
>> Yes, but it doesn't mean it should be the default.
>
> I didn't say it should be.
>
>> In my workflows, the first thing that matters is what commit did what
>> changes on the current branch. I don't typically care what the user
>> changed during the merge operation, only about the result. If I do care,
>> then only after I find the merge commit is responsible, and I can then
>> use --cc if I want to.
>>
>> > 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.
>>
>> No, it's exactly this merge commit that made these changes to the
>> current branch. The changes you refer to have been made on another
>> branch, and not by this particular merge commit, and we fortunately have
>> the reference to those commits through the second parent of this one.
>
> If you only care about "what introduced these changes to the current
> branch", then it's not only the diff against second parent that is
> irrelevant: ALL commits that are part of the history only via the
> second or later parents are also irrelevant and thus you should be
> using --first-parent when asking this question.  That changes both
> history traversal and the diff output.

No, it's exactly why I don't always want --first-parent. I want to
traverse *all* the history, yet to see what's changed by every commit on
*this* branch in the process of traversal, be it a merge on not a merge
commit.

Thanks,

-- Sergey Organov