Re: [PATCH v2] rebase --merge: optionally skip upstreamed commits

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.