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

From: Paolo Bonzini <bonzini@gnu.org>
Date: Mar 18, 2010, 07:14 UTC
Message-ID: <f865508f1003180014q3add26d1p8d213994df1961c3@mail.gmail.com>
In-Reply-To: <201003180138.56529.chriscool@tuxfamily.org>

On Thu, Mar 18, 2010 at 01:38, Christian Couder <chriscool@tuxfamily.org> wrote:

Show 13 quoted lines

> On Wednesday 17 March 2010 18:01:53 Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> 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