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

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