Jonathan Nieder <jrnieder@xxxxxxxxx> 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. -- 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