Sergey Organov <sorganov@xxxxxxxxx> writes: > Previous description implicitly favored 'true' value for "pull.rebase" > and "pull.<branch>.rebase" options, I do not share that impression. It is true that 'true' is described first before 'preserve', which can be argued that it is being implicitly favoured, but we have to pick one over the other when describing two things, so I do not see it as a strong preference. > when for some workflows 'preserve' > is the right choice, and for others it hardly makes any difference. > Therefore, 'preserve' should be preferred in general, unless the user > knows exactly what she is doing. I doubt we saw any such conclusion in the recent thread that discussed this, other than your repeating that statement---and I've learned to tell repeated voices and chorus apart over time ;-). One approach is more suitable for some workflows while being inappropriate for others and that goes for both variants. A downside of flattening is that it gives a wrong result when the user wants to keep merges. Two downsides of preserving are that it gives a wrong result when the user wants to flatten, and it tends to be slower. During that discussion, you seemed to assume that those who want a flattened end result would never merge locally; I do not think that is true. Having your own merges on a branch that you would want to rebase to flatten is not unusual. You may employ a workflow to build on separate topic branches while developing, merge the topics among them that are ready into your local 'master' to be used personally, and after using it from your local 'master' for a while to make sure it is solid, you may decide to make it final by publishing it to the outside world, and at that point you would want to flatten the history on top of the latest upstream before pushing. That's not anything advanced that takes " the user knows exactly what she is doing." -- 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