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

[Junio C Hamano <gitster@pobox.com>]

There is another thing.

> Using `exec git cherry-pick ... -x` does work, ...

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