On Thu, Mar 26, 2020 at 10:50 AM Jonathan Tan <jonathantanmy@xxxxxxxxxx> wrote: > > > New in V2: changed parameter name, used Taylor's commit message > > suggestions, and used Elijah's documentation suggestions. > > I think the discussion has shifted away from whether this functionality > is desirable (or desirable and we should implement this functionality > without any CLI option) to the name and nature of the CLI option. Before > I send out a new version, what do you think of using this name and > documenting it this way: > > --keep-cherry-pick=(always|never):: > Control rebase's behavior towards commits in the working > branch that are already present upstream, i.e. cherry-picks. > + > If 'never', these commits will be dropped. Because this necessitates > reading all upstream commits, this can be expensive in repos with a > large number of upstream commits that need to be read. > + > If 'always', all commits (including these) will be re-applied. This > allows rebase to forgo reading all upstream commits, potentially > improving performance. > + > The default is 'never'. > + > See also INCOMPATIBLE OPTIONS below. > > I've tried to use everyone's suggestions: Junio's suggestions to use the > "keep" name (instead of "detect", so that we also communicate what we do > with the result of our detection) and the non-boolean option (for > extensibility later if we need it), and Elijah's suggestion to use > "cherry-pick" instead of "duplicate". If this sounds good, I'll update > the patch and send out a new version. Sounds good to me. Thanks!
