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

[Sergey Organov <sorganov@gmail.com>]

Hi,

Jonathan Nieder <jrnieder@gmail.com> writes:

> Hi,
>
> Elijah Newren 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.
>
> I agree.  The --diff-merges=remerge behavior has also been the default
> in Gerrit since time immemorial, and when I first started using Gerrit
> it was one of my favorite things about it.

Due to previous set of diff-merges patches you now can set
log.diffMerges=remerge and have fun having it as the default for "-m" in
pure Git. I've introduced log.diffMerges exactly because I do realize
that different people and different workflows might have different
preferences here.

> That is because it shows the human content of the merge: it shows
> exactly what changes were made after the automated part was done.

No, in fact it shows what additional changes were to be made if the
merge had been achieved using particular automated merge algorithm you
apply right now. Provided you utilize no external knowledge, you have no
idea how merge has been in fact achieved, as core Git (fortunately)
neither cares nor stores such information.

Contrary to your view, and I believe more inline with Git core
philosophy, I (usually) don't care *how* particular changes were
achieved, I rather care *what* they are, so pure diff to the first
parent is the best basic format for me. Only if I need to see *why* the
changes are this particular way, I'd use advanced tools and formats to
get to the best *guess*, and that's where these advanced formats get
handy.

In other words, for me merge commit is mostly *commit*, and only then
it's *merge*: "here are the changes, and, by the way, here is where
these changes came from."

That said, please don't get me wrong: I'm all for advanced features such
as --diff-merges=remerge, as I do understand how and when they are
useful, I just personally won't make them active by default.

>
> I don't have a strong opinion about what the default for -m should be.
>
>> 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.

I do have strong opinion. --diff-merges=1 is the only sensible
factory-default. Not only it has no implicit assumptions about how given
commit has been achieved, it's also the only format even entire Git
newbie might already be familiar with.

Then, --cc and I suspect "remerge" too, give exactly empty output most
of times, that'd cause even more surprises when one of them is the
default: you enable diff for merges, but still get nothing. OTOH,
--diff-merges=1 will give empty output if and only if given commit
actually brings no changes to the branch, exactly as any commit out
there. No surprises at all.

Principle of least surprise is still a good thing to follow.

Thanks,
-- Sergey Organov