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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 7, 2010, 03:55 UTC
Message-ID: <7v6358dbv8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100306203447.2960.42019.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

Show 7 quoted lines

> 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"?