Hi, Jonathan Nieder <jrnieder@xxxxxxxxx> 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
