> How should this interact with 949e0d8e (pull: require choice between > rebase/merge on non-fast-forward pull, 2013-06-27) I believe there should not be any conflicts in functionality, other than just tweaking the docs to mention --rebase=preserve as an option. Personally, I would assert that, for people using a rebase workflow with "git pull", --prebase=preserve should be the default behavior, otherwise they'll be surprised when their feature branches get flattened. Unfortunately, we can't change the behavior of the naked "--rebase" flag to really mean "--rebase=preserve", but I think that would be ideal. I think it's what people mean they do "git pull". If you want a more raw rebase, they would likely (I think/assume) be running "git rebase" directly. Nonetheless, thanks for pointing out 949e0d8e, I did not know about it. Perhaps after that commit graduates to master, I can base this commit on it, and tweak the new docs to suggest --rebase=preserve as the least-surprising behavior. (Since I'm offering opinions, I think --rebase=preserve would be a great default for "git pull" in 2.0, but please ignore this statement if you've already hashed out the future/2.0 behavior of git pull.) - Stephen -- 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