On Thu, Mar 18, 2010 at 01:38, Christian Couder <chriscool@xxxxxxxxxxxxx> wrote: > 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. > > 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. FWIW, I had a use-case for git cherry-pick yesterday. I had submitted many unrelated patches to a project where I am committer (but I still need reviews before pushing) and placed them on a single branch for testing. Almost always the reviews would happen in the order that I sent, but I wasn't sure so my workflow would be necessarily cherry-pick + test + push + rebase. Having the possibility to do an optional fast forward would limit the need to rebase and thus the time spent for each cherry-pick+push+rebase. Paolo -- 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