git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Stefan Haller <lists@haller-berlin.de>,  Git <git@vger.kernel.org>
Subject: Re: Thoughts about the -m option of cherry-pick and revert
Date: Fri, 21 Jun 2024 09:34:22 -0700	[thread overview]
Message-ID: <xmqqv822ntkh.fsf@gitster.g> (raw)
In-Reply-To: <6e71b1f3-599f-49c3-be37-e499f28983cf@gmail.com> (Phillip Wood's message of "Fri, 21 Jun 2024 11:19:31 +0100")

Phillip Wood <phillip.wood123@gmail.com> 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.

  parent reply	other threads:[~2024-06-21 16:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-20 10:05 Thoughts about the -m option of cherry-pick and revert Stefan Haller
2024-06-21  2:03 ` Junio C Hamano
2024-06-21  6:33   ` Stefan Haller
2024-06-21 10:19     ` Phillip Wood
2024-06-21 11:48       ` Stefan Haller
2024-06-21 16:34       ` Junio C Hamano [this message]
2024-06-24  7:33         ` Stefan Haller
2024-06-24 18:43           ` Junio C Hamano
2024-06-21 10:12   ` Phillip Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqv822ntkh.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=lists@haller-berlin.de \
    --cc=phillip.wood123@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).