Re: Thoughts about the -m option of cherry-pick and revert

From: Stefan Haller <lists@haller-berlin.de>
Date: Jun 21, 2024, 06:33 UTC
Message-ID: <dd58a60d-a551-4726-85a7-f47b851914be@haller-berlin.de>
In-Reply-To: <xmqqa5jfoxvh.fsf@gitster.g>

On 21.06.24 04:03, Junio C Hamano wrote:

Show 10 quoted lines

> Stefan Haller <lists@haller-berlin.de> writes:
> 
>> - Wouldn't it make sense to default to -m1 when no -m option is given?
> 
> Given that the current behaviour was chosen to make sure that the
> user is aware that the commit being reverted/cherry-picked is a
> merge and has a chance to choose the right parent (as opposed to
> blindly picking the first parent that happened to be the right one
> by accident), I am not sure if it is prudent to change the
> behaviour.

Hm, in all example scenarios I experimented with, picking the wrong parent would result in an empty diff, and consequently an error message like this:

   nothing to commit, working tree clean
   The previous cherry-pick is now empty, possibly due to conflict
   resolution.
   If you wish to commit it anyway, use:

       git commit --allow-empty

   Otherwise, please use 'git cherry-pick --skip'

I'm not sure if this error is easier or harder to understand than the one you get today when omitting -m, but we could probably improve it by mentioning the -m option if the cherry-picked commit was a merge.

I'd be interested in example scenarios where both sides of the merge have non-empty diffs. Won't this only happen for evil merges?

Show 5 quoted lines

> If I were simplifying this, I would probably
> 
>  (1) disallow cherry-picking a merge (and suggest redoing the same
>      merge, possibly after rebasing the copy of the merged history
>      to an appropriate base as needed), and

This seems unnecessarily restrictive to me. Cherry-picking merge commits using -m1 is useful, it's an important part of our release workflow at my day job.

>  (2) allowing reverting a merge only wrt the first parent,

Interesting, that's what I'm considering doing in lazygit (except for both revert and cherry-pick), but I kind of didn't expect much support for that idea. :-)

-Stefan