[RFC] should `git rebase --keep-base` imply `--reapply-cherry-picks` ?

[Philippe Blain <levraiphilippeblain@gmail.com>]

Hello,

I learned today that doing `git rebase --keep-base master` 
will drop commits that were cherry-picked from master to the current branch. 
I was simply doing a code clean up on my feature branch (the full command was
`git rebase -i --keep-base master`), and this kind of confused me for a moment.

Is this a sane default ? I understand that it is a good default when we are rebasing 
*on top* of master, but here I'm just doing some squashing and fixup's and I did not
want the commit I had cherry-picked from master to disappear (yet). In fact, because it
was dropped, it created a modify/delete conflict because in a subsequent commit 
in my feature branch I'm modifying files that are added in the commit I cherry-picked.

How would a change that made '--reapply-cherry-picks' be the default when using 'keep-base'
be received ?

Tangential question: in any case, would it make sense to still add the "dropped because 
already upstream" commits to the todo list, in the case of an interactive rebase ? 
(maybe commented out, or listed as 'drop' with some kind of comment saying those 
are dropped because they appear textually upstream?)

Cheers,
Philippe.
P.S. I CC'd those who were involved with the 'keep-base' patch or the 'reapply-cherry-picks' patch.