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

On Thu, Mar 18, 2010 at 01:38, Christian Couder [off-list ref] wrote:

On Wednesday 17 March 2010 18:01:53 Junio C Hamano wrote:

quoted

Jonathan Nieder [off-list ref] writes:

quoted

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