On 24/01/2023 17:12, Elijah Newren wrote:
On Tue, Jan 24, 2023 at 8:48 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
+ options.reapply_cherry_picks = keep_base;
+ else if (!keep_base)
+ /*
+ * --keep-base implements --reapply-cherry-picks by
Should this be --[no-]reapply-cherry-picks, to clarify that it handles
both cases? Especially given how many times I missed it?
This has obviously proved to be confusing. The aim was to explain that
in order to work with the apply backend "[--reapply-cherry-picks]
--keep-base" was doing something unusual with `upstream` to reapply
cherry picks. "--no-reapply-cherry-picks --keep-base" does not do
anything unusual with `upstream`. I don't think changing it to
--[no-]reapply-cherry-picks quite captures that. I came up with
To support --reapply-cherry-picks (which is not supported by the apply
backend) --keep-base alters upstream to prevent cherry picked commits
from being dropped.
but it really needs to mention that --keep-base also supports
--no-reapply-cherry-picks in the usual way
Somewhat wordy, but perhaps:
/*
* The apply backend always searches for and drops cherry
* picks. This is often not wanted with --keep-base, so
* --keep-base allows --reapply-cherry-picks to be
* simulated by altering the upstream such that
* cherry-picks cannot be detected and thus all commits are
* reapplied. Thus, --[no-]reapply-cherry-picks is
* supported when --keep-base is specified, but not when
* --keep-base is left out.
*/
That sounds good to me, it is definitely an improvement on the current
comment which I think is too terse.
Best Wishes
Phillip
