Re: cc/cherry-pick-ff (Re: What's cooking in git.git (Mar 2010, #04; Tue, 16))

Jonathan Nieder [off-list ref] writes:

For what it’s worth, I am not convinced about the --no-ff option.  I do
not think --ff ever will be the default: for an operation that amounts
to applying a patch and making a new commit, it just feels wrong.

Same here ;-) and because of that, --no-ff as an undocumented feature
feels doubly wrong to me.  If some scripts use it, people would wonder
what that no-op option is doing there.  Perhaps we should discard the bits
about --no-ff to make it more clear that --ff is an oddball case that is
meant only for supporting what "rebase-i" (and other tools that reinvent
and enhance it) does.

For the same reasoning, you may have liked the "do not fast-forward the
early part of 'rebase -i' even if the commits are picked literally" patch,
by Marc.