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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 20, 2010, 14:20 UTC
Message-ID: <7v1vffqdm4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201003180138.56529.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

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

That doesn't make any sense to me.

Think why you are saying A..B, with an explicit "A".

It is because you know it is different from HEAD; otherwise you would have done "git merge B"---slurp all changes between HEAD..B, which would be equivalent to "cherry-pick --ff HEAD..B".

As an ingredient for use of scripts that do not want to check (even if they could) if it is dealing with a corner case in which the commit a change is being applied to happens to be the commit the change in question is based on, being able to say --ff would make sense (as your patch series showed, it helped to lose several lines from the rebase-i implementation). The end user may not bother to count commits, and being able to ff earlier parts of "rebase -i HEAD~20" when the first "edit" appears after many "pick" would help (and that was why "rebase -i" internally had ff logic).

But running cherry-pick as the top-level operation is a conscious act of "I want to replay the change done by that one", and it would be utterly confusing if it fast-forwarded by default. I agree with Jonathan that it will never be default.