Re: [PATCH] cherry-pick: do not error on non-merge commits when '-m 1' is specified

On Tue, Mar 26, 2019 at 3:20 PM Jeff King [off-list ref] wrote:

On Tue, Mar 26, 2019 at 03:07:42PM -0700, Elijah Newren wrote:

quoted

On Tue, Mar 26, 2019 at 9:35 AM Jeff King [off-list ref] wrote:

quoted

On Mon, Mar 25, 2019 at 09:43:09AM +0300, Sergey Organov wrote:

quoted

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).