Paolo Bonzini <bonzini@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html