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

From: Junio C Hamano <[email-masked]>
Date: Fri, 21 Jun 2024 09:34:22 -0700

Phillip Wood <[email-masked]> writes:

> 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?

One case that comes to my mind is when you failed to plan ahead and
used a wrong base when building a series to "fix" an old bug.  You
built a 7-patch series to fix a bug that you introduced in release
1.0, but instead of basing the fix on maint-1.0 maintenance track,
you forked from the tip of master that is preparing for your next
feature release that is release 1.4.

Even if you realized that the fix is important enough to warrant
applying to the maint-1.0 maintenance track, you cannot merge the
topic that houses 7-patch series down to the old maintenance track
without bringing all the new features that happened since 1.0 on the
master track.

A kosher way may be to rebase the 7-patch series to maint-1.0 and
merge the result into the maint-1.0 track (and upwards if needed).
But cherry-picking the commit that merged the original "fix" topic
into master _may_ be simpler, as you need to resolve a larger
conflict but (hopefully) only once, instead of up to 7 times, once
per each commit on the "fix" topic while rebasing.

But of course if something goes wrong, it makes the result
impossible to bisect---exactly the same reason why you should think
twice before doing a "merge --squash".  In addition, if you somehow
figured out why the cherry-picked fix was inadequate, you'd now need
to forward-port the fix for the fix to the master track or whereever
the cherry-picked-merge was taken from.

On the other hand, if the original "fix" branch was rebased on
maint-1.0 and then further fixed, the result can be merged to
maint-1.0 as well as all the way to the master track.

So, I can understand why people may want to cherry-pick a merge,
I suspect it is a false economy.  Optimizing for picking, paying
higher price when the result of (incorrect) picking has to be
corrected later.