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, 09:05 UTC
- Message-ID
- <7vy6i4zem7.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4B936500.9020005@gnu.org>
Paolo Bonzini <bonzini@gnu.org> writes:
Show 6 quoted lines
> 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.