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

From: Christian Couder <chriscool@tuxfamily.org>
Date: Mar 18, 2010, 00:38 UTC
Message-ID: <201003180138.56529.chriscool@tuxfamily.org>
In-Reply-To: <7vwrxaubjy.fsf@alter.siamese.dyndns.org>

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

Show 11 quoted lines

> 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.  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.