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

From: Jeff King <peff@peff.net>
Date: Mar 26, 2019, 16:32 UTC
Message-ID: <20190326163204.GC29627@sigill.intra.peff.net>
In-Reply-To: <87h8bra1z6.fsf@javad.com>

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.

> Also, is current output of "git log -m", being extremely confusing,
> suitable for anything? Maybe consider to change it to output diff with
> respect to the first parent only? Though it's then a pity "-m" lacks
> argument here, similar to what it has in cherry-pick.

I've used "-m" without "--first-parent" sometimes in order to track down mis-merges manually. It's not usually a big deal to say "--first-parent" if that's what you want. But one thing I don't think is currently possible is to ask only for the first-parent diff, but _not_ restrict the actual traversal.

If that's what you mean by giving an argument to "-m", then yeah, I think that would be a useful addition.

-Peff