On Tue, Mar 26, 2019 at 3:20 PM Jeff King <peff@xxxxxxxx> wrote: > > On Tue, Mar 26, 2019 at 03:07:42PM -0700, Elijah Newren wrote: > > > On Tue, Mar 26, 2019 at 9:35 AM Jeff King <peff@xxxxxxxx> wrote: > > > > > > On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote: > > > > > > > How about changing "git show -p M" to output "diff -p M^ M" rather than > > > > "diff-tree --cc M" for merge commits? It's really surprising specifying > > > > -p has no visible effect. > > > > > > That's because "-p" is already the default, and the format selection is > > > orthogonal to the handling of merge commits. Providing "-m" would > > > actually override the "--cc" default (though "--first-parent -m" is > > > likely to be less noisy, per this discussion). > > > > > > As far as defaults go, I dunno. The idea is that "--cc" would give you a > > > nice summary of what the merge _itself_ had to touch. I think that's > > > valuable, too. If we were starting from scratch, I think there could be > > > a discussion about whether one default is better than the other. But at > > > this point I have a hard time finding one so much obviously better than > > > the other to merit changing the behavior. > > > > Indeed, some of us would view a first parent diff default for merges > > as problematic. However, I'd like to point out (or remind) that these > > two options aren't the only ways you could view a merge. Thomas > > Rast's --remerge-diff[1] is another (even if not yet part of git.git). > > Gerrit uses something similar-ish for its default way of showing a > > merge. > > Heh, I almost mentioned remerge-diff, but since it's not actually part > of Git, I didn't want to get into a tangent. But since you mention it, > yes, I actually find it quite a useful way of looking at the diff, > especially when I want to see what the person resolving the conflicts > actually _did_. The --cc combined diff is too eager to throw away hunks > that resolved purely to one side (which _most_ of the time is what you > want, but when you're hunting a possible error in the merge, it's quite > confusing). > > How close is merge-recursive.c to actually doing a pure in-memory merge? > > I seem to recall that was a (the?) sticking point for the original > remerge-diff. Doing a pure in-memory merge is tied up with my overall merge-recursive rewrite, but I haven't touched merge stuff in quite a while now other than the recent make-directory-rename-detection-be-a-conflict-by-default stuff. I'm hoping I can finish that soon (though I've struggled a bit to find the time to do so), and finish out the filter-repo stuff, then I plan to get back to merge stuff again. A pure in-memory merge is near the top of my priorities for the rewrite, so we'll get it...eventually. (Maybe a Christmas present?) I do think there's more than just that sticking point for the remerge-diff, but the other things are on my radar too (a few slots later on my todo list).
