On 21.06.24 04:03, Junio C Hamano wrote: > Stefan Haller <lists@xxxxxxxxxxxxxxxx> 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? > 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