Re: [PATCH] rebase -i: introduce `pick -x` to add "cherry picked from commit ..."

There is another thing.

Does it really work? I seem to recall there is a reason why "pick" insn in the rebase todo list and "exec git cherry-pick" would not work identically and the distinction is rather deliberate.

Rebase copies the notes attached to the original commits to the corresponding rewritten commits. This is because rebase is a way to _move_ an existing (and hopefully not yet published) history on top of some other base, with the full intention to destroy, abandon, remove, and forget about the original history, and nobody will see the original commits after the rebase is finished. Copying notes, therefore, is a sensible way to preserve the data, as these new commits fully _replace_ the old ones.

On the other hand, cherry-pick is about _duplicating_ a parallel history in a new context that is separate from the original, while preserving the original history. Since the expectation is that the original history will be kept (and not rewritten---otherwise the "cherry picked from ..." comment will totally be useless), and the new commits are being created to live in their own new _context_, notes are not carried over.

As can be seen in the mental model above, "rebase" by its nature is what you do with the intention not to keep the original. From that point of view, "pick -x" is a poor fit in the context, because for the result from "cherry-pick -x" to be any useful, the original commit you made the picked commit out of MUST be known to those who learn the fact that this new commit was cherry-picked from that other commit. It goes directly opposite to what "rebase" does, in that the point of rebase is to destroy "that other commit" and make sure nobody will see it after rebase is done.

So...