From: Paolo Bonzini Date: Thu, 18 Mar 2010 07:14:14 GMT Subject: Re: cc/cherry-pick-ff (Re: What's cooking in git.git (Mar 2010, #04; Tue, 16)) Message-ID: In-Reply-To: <201003180138.56529.chriscool@tuxfamily.org> On Thu, Mar 18, 2010 at 01:38, Christian Couder wrote: > On Wednesday 17 March 2010 18:01:53 Junio C Hamano wrote: >> Jonathan Nieder 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