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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 21/06/2024 07:33, Stefan Haller wrote:
On 21.06.24 04:03, Junio C Hamano wrote:
Stefan Haller <lists@xxxxxxxxxxxxxxxx> writes:
>
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.

That might be helpful - if we do that we'd want to make sure that the user can retry this pick with "-m" without restarting the whole cherry-pick.

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?

I think you'd need a conflicting merge that is resolved in a way that the resolution of the conflicting lines doesn't match either parent. (I assume that's what you mean by evil but I thought it best to check)

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.

I can see why people want to revert merges but cherry-picking them always feels strange to me - what is the advantage over actually merging the branch and seeing the full history of that commit?

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

For lazygit I would think it would be fine to be a bit more restrictive that git as anyone with an unusual requirement can always fall back to using git for that.

Best Wishes

Phillip


-Stefan






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux