Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > 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. I think they rather ask for avoiding tons of meaningless automatic merges resulting from periodic pulling from upstream. Those subset of the above who only do small discrete patches don't do merges to their tracking branches, except by mistake, right? If so, 'pull --rebase=preserve' makes no difference compared to --rebase=true to their normal workflow. Moreover,if someone merges something to his tracking branch by mistake, how is it different from making merge to any other branch by mistake? Just fix the mistake by resetting to previous state. On the other hand, if someone decides to merge something else to his tracking branch by purpose, both --rebase=preserve and --rebase=false perform as expected, while --rebase=true may easily lead to huge surprise. Please refer also to this thread for one such case: http://www.mail-archive.com/git%40vger.kernel.org/msg55605.html > 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. Once again, in case of mistake they are free to use --rebase=true, and even then using 'git rebase' directly is probably cleaner. That said, I don't argue --rebase=true could be sometimes useful. It's just that I think --rebase=preserve is safer, so it should be a good idea to suggest to use it (in favor of --rebase=true) in general. > That said, in some specific workflows, --rebase=preserve may work > better than --rebase=true. It does indeed, and I don't think my aforementioned workflow is too specific. > My hunch is that even those workflows are not currently handled well > with --rebase=preserve, alas. --rebase=preserve works fine for the aforementioned workflow. At least simple tests I performed so far ran fine. I'd like to learn though which nasty drawbacks --rebase=preserve has for tracking branches compared to --rebase=true, if any. > 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. That would be an improvement anyway, indeed. -- Sergey. -- 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