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