Re: [PATCH v4 3/7] revert: add --ff option to allow fast forward when cherry-picking

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

Christian Couder <chriscool@tuxfamily.org> writes:

> From: Junio C Hamano <gitster@pobox.com>
>
> As "git merge" fast forwards if possible, it seems sensible to
> have such a feature for "git cherry-pick" too, especially as it
> could be used in git-rebase--interactive.sh.
>
> Maybe this option could be made the default in the long run,

I never said that.

For scripted use, like we can see in your [PATCH 7/7], "cherry-pick --ff"
could be a good ingredient (but even then the calling Porcelain script may
already know that what is being picked is a direct descendent (rebase -i
certainly should, as the last commit it processed from the todo file is at
the HEAD), but for manual use case it just feels silly to assume that the
end user is so stupid that s/he doesn't know the commit being picked might
be a direct descendant, which would be the only reason why making --ff the
default might make sense.

And adding --no-ff and sprinkling that to scripts, only to support that
default change as a future possibility, feels doubly silly.

What was the real motive/use case of "cherry-pick --ff"?