Sergei Organov wrote: > Is there any scenario at all where pull --rebase=true wins over > preserve? Basically always in my book. ;-) When people turn on 'pull --rebase', they are asking for a clean, simplified history where their changes are small discrete patches in a clump on top of upstream. When someone has made a merge by mistake (with 'git pull' before remembering to do an autosetuprebase, or with 'git merge' instead of cherry-picking some patches they needed), the current --rebase=true behavior can be a good way of cleaning up. That said, in some specific workflows, --rebase=preserve may work better than --rebase=true. My hunch is that even those workflows are not currently handled well with --rebase=preserve, alas. A clearer explanation of --rebase (maybe with sub-headings for each choice *true*, *false*, and *preserve*?) sounds useful. An illustration in the EXAMPLES section of git-pull(1) of the difference between these three modes and when to use them would be even more helpful. Thanks, Jonathan -- 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