On 21/06/2024 03:03, Junio C Hamano wrote:
Stefan Haller <lists@xxxxxxxxxxxxxxxx> writes:
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.
FWIW I agree with this, for me the main benefit of the current behavior
is stopping when I'm not expecting to cherry-pick a merge.
Best Wishes
Phillip
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
(2) allowing reverting a merge only wrt the first parent,
but that is a different story.
