On Saturday 20 March 2010 15:20:03 Junio C Hamano wrote: > Christian Couder <chriscool@xxxxxxxxxxxxx> 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". I think that some people might avoid "git merge" altogether just because they may not be confident with merges and prefer linear histories. They may also prefer "git cherry-pick A..B" over "git rebase" or "git rebase - i" because it may be simpler for them to understand. > 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. Well, I think it is difficult to predict how and how much people will use "git cherry-pick A..B", and if after using it they will want fast forwarding by default to be consistent between "git cherry-pick" and "git merge" or if they won't care. Best regards, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html