On Jan 18, 2008 1:25 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > ... > So keep it simple, and do not use Octopus if there is no > justification other than "it looks cool" you can come up with. > > I do not mind a patch to git-merge-octopus to discurage its use > even more by detecting the casen where some of the merged > branches are not independent and refusing to work, but that is > a post 1.5.4 topic. Instead of refusing to work, such merge commits can be fast forwarded, recorded as a "normal" commit with two children, or an octopus with fewer children than those specified by the user. The more I think about this is that --ff-only should really be specified as a merge strategy (single) and not as an special case of --ff. All merge strategies can then take any number of commits, but will only succeed if the commits can be reduced down to two or fewer for resolve/recursive and one for single. Commit reduction is simpler for single than the other merge strategies. I suggest we keep it simple and implement this new feature as a merge strategy and the commit reduction is only done for fast-forward. I will create a good number of test cases so we should be comfortable with this new feature. A later patch will implement the commit reduction for the other merge strategies. --no-ff will then have the meaning: No fast forward of any commit. All commits specified by the user will be recorded. -- Sverre Hvammen Johansen - 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
