Nico Williams <n...@cryptonector.com> writes:
> On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder <jrnie...@gmail.com> wrote:
>> 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.
> +1. Words to develop by.
> There are exceptions. E.g., when you pull commits from multiple
> [forked] upstreams, then you can't keep your local commits on top.
> That exception aside, keeping all local commits "on top" by always
> rebasing them onto the upstream is extremely useful: a) in simplifying
> conflict resolution, b) making it easy to identify as-yet-unintegrated
> local commits, c) making it easy to contribute local commits.
But 'pull --rebase=preserve' does rebase local commits onto the
upstream, and result is exactly the same as 'pull --rebase=true', unless
you have some of your own merges to be rebased. That's where the
difference between these two options appears. It's --rebase=false that
performs merges rather than rebase.
Overall, I still can't see where '--rebase=true' wins over
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