On Sunday 07 March 2010 10:05:04 Junio C Hamano wrote: > Paolo Bonzini <bonzini@xxxxxxx> writes: > > On 03/07/2010 04:55 AM, Junio C Hamano wrote: > >> What was the real motive/use case of "cherry-pick --ff"? > > > > Avoiding pointless separation of histories. It's true that nowadays > > git-patch-id will make a good job of reconciling them, but they do > > look ugly in gitk. > > Sorry, but that is a not-very-useful XY answer. > > Why were _you_ using "cherry-pick" on a commit that is an immediate child > of the current commit? What were you trying to achieve by blindly using > cherry-pick even in such a case? > > I am sort-of guessing that "blindly" is coming from a script that doesn't > bother to check if the commit you are cherry-picking is a direct child, > and I do not think it is such a bad thing to allow scripts to blindly call > cherry-pick that way and at the same time avoid making cherry-picked > commits that are unnecessary. So in that sense I am not opposed to having > an option to allow "--ff". > > But if that is the real motivation, then making --ff default is a wrong > thing to do, as existing scripts knew and trusted cherry-pick will _not_ > fast-forward, and the ones that do want fast-forward have already checked > just like "rebase -i" does. Changing the default like Chriscool suggested > would not help anybody. The wording is: "Maybe this option could be made the default in the long run, ..." I didn't wrote something like: "This option should be made the default in the long run, ..." I really didn't know if it should or should not be made the default now or in the long run, but I thought I had to talk about it. Why? Because Paolo said that he would like it to become the default, and also because if we implement "git cherry-pick A..B" and people start to use it a lot, they may find it boring to have to always add --ff to avoid creating lots of spurious commit (instead of reusing existing ones). Now if you want me to remove this part of the commit message, I will do it. But my opinion is that it is interesting to document that we thought about making it the default now or in the future. Do you prefer something like: "Making this option the default was discussed on the mailing list but we decided that it is best left as non default for now. Though we recognized that it is best to have a --no-ff option too to future proof scripts in case the decision to make fast forwarding the default is made in the future." ? 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