On Wednesday 17 March 2010 18:01:53 Junio C Hamano wrote: > 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. My opinion is that if we implement "git cherry-pick A..B", and if many people start to use it, then perhaps it will make sense for --ff to become the default. Because people may not want to have to remember using --ff to avoid many spurious commits to be created. And having --ff and --no-ff makes "git cherry-pick" consistent with "git merge" which has both. And --ff is the default for "git merge", so consistency will be an argument to make it the default for "git cherry-pick" if "git cherry-pick A..B" is used a lot. Best regards, Christian. -- 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