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

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

Paolo Bonzini <bonzini@gnu.org> writes:

> On 03/07/2010 04:55 AM, Junio C Hamano wrote:
>> What was the real motive/use case of "cherry-pick --ff"?
>
> Avoiding pointless separation of histories.  It's true that nowadays
> git-patch-id will make a good job of reconciling them, but they do
> look ugly in gitk.

Sorry, but that is a not-very-useful XY answer.

Why were _you_ using "cherry-pick" on a commit that is an immediate child
of the current commit?  What were you trying to achieve by blindly using
cherry-pick even in such a case?

I am sort-of guessing that "blindly" is coming from a script that doesn't
bother to check if the commit you are cherry-picking is a direct child,
and I do not think it is such a bad thing to allow scripts to blindly call
cherry-pick that way and at the same time avoid making cherry-picked
commits that are unnecessary.  So in that sense I am not opposed to having
an option to allow "--ff".

But if that is the real motivation, then making --ff default is a wrong
thing to do, as existing scripts knew and trusted cherry-pick will _not_
fast-forward, and the ones that do want fast-forward have already checked
just like "rebase -i" does.  Changing the default like Chriscool suggested
would not help anybody.

That is what I wanted to find out.