Re: [PATCH 0/5] rebase --keep-base: imply --reapply-cherry-picks and --no-fork-point

From: Jonathan Tan <jonathantanmy@google.com>
To: Phillip Wood via GitGitGadget <gitgitgadget@gmail.com>
Cc: Jonathan Tan <jonathantanmy@google.com>,
	git@vger.kernel.org,
	Philippe Blain <levraiphilippeblain@gmail.com>,
	Denton Liu <liu.denton@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH 0/5] rebase --keep-base: imply --reapply-cherry-picks and --no-fork-point
Date: Wed, 24 Aug 2022 15:27:03 -0700	[thread overview]
Message-ID: <20220824222703.1685763-1-jonathantanmy@google.com> (raw)
In-Reply-To: <pull.1323.git.1660576283.gitgitgadget@gmail.com>

"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> A while a go Philippe reported [1] that he was surprised 'git rebase
> --keep-base' removed commits that had been cherry-picked upstream even
> though to branch was not being rebased.
[...]
> [1]
> https://lore.kernel.org/git/0EA8C067-5805-40A7-857A-55C2633B8570@gmail.com/

In the thread at [1] I said that (in [2]) I expected that
--reapply-cherry-picks would be the default, but this implicit
--no-reapply-cherry-picks (in order to automatically exclude certain
commits) is a long-available and long-advertised feature. So I
symphatize with making certain modes of rebase automatically imply
--reapply-cherry-picks, but I think that either all modes (as much as
possible) should imply it, or no mode should imply it.

Having said that, I already looked at the code so I have included my
review comments anyway (in case we do decide to have implied
--reapply-cherry-picks for --keep-base but not for other cases).

As for the --fork-point part, I made a comment in my reply to patch 5.

[2] https://lore.kernel.org/git/20200714035104.1465772-1-jonathantanmy@google.com/