From: Phillip Wood Date: Fri, 21 Jun 2024 10:19:31 GMT Subject: Re: Thoughts about the -m option of cherry-pick and revert Message-ID: <6e71b1f3-599f-49c3-be37-e499f28983cf@gmail.com> In-Reply-To: On 21/06/2024 07:33, Stefan Haller wrote: > On 21.06.24 04:03, Junio C Hamano wrote: >> Stefan Haller 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 >