Sergey Organov <> 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

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
More majordomo info at

Reply via email to