From: Stephen Haberman <stephen@exigencecorp.com>
Date: Mon, 12 Aug 2013 17:04:50 GMT
Subject: Re: [PATCH] pull: Allow pull to preserve merges when rebasing.
Message-ID: <20130812120450.47f785b2@sh9>
In-Reply-To: <7viozbz950.fsf@alter.siamese.dyndns.org>


> How should this interact with 949e0d8e (pull: require choice between
> rebase/merge on non-fast-forward pull, 2013-06-27)

I believe there should not be any conflicts in functionality, other
than just tweaking the docs to mention --rebase=preserve as an option.

Personally, I would assert that, for people using a rebase workflow with
"git pull", --prebase=preserve should be the default behavior, otherwise
they'll be surprised when their feature branches get flattened.

Unfortunately, we can't change the behavior of the naked "--rebase"
flag to really mean "--rebase=preserve", but I think that would be
ideal. I think it's what people mean they do "git pull". If you want a
more raw rebase, they would likely (I think/assume) be running "git
rebase" directly.

Nonetheless, thanks for pointing out 949e0d8e, I did not know about it.

Perhaps after that commit graduates to master, I can base this commit
on it, and tweak the new docs to suggest --rebase=preserve as the
least-surprising behavior.

(Since I'm offering opinions, I think --rebase=preserve would be a great
default for "git pull" in 2.0, but please ignore this statement if
you've already hashed out the future/2.0 behavior of git pull.)

- Stephen