Sergei Organov wrote:
> Is there any scenario at all where pull --rebase=true wins over
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html