Re: [PATCH] pull: Allow pull to preserve merges when rebasing.

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 8, 2013, 21:20 UTC
Message-ID: <alpine.DEB.1.00.1308082314320.24252@s15462909.onlinehome-server.info>
In-Reply-To: <1375983492-32282-2-git-send-email-stephen@exigencecorp.com>

Hi Stephen,

On Thu, 8 Aug 2013, Stephen Haberman wrote:

Show 10 quoted lines

> If a user is working on master, and has merged in their feature branch,
> but now has to "git pull" because master moved, with pull.rebase their
> feature branch will be flattened into master.
> 
> This is because "git pull" currently does not know about rebase's
> preserve merges flag, which would this behavior, and instead replay on
> the merge commit of the feature branch onto the new master, and not the
> entire feature branch itself.
> 
> Add a -p/--preserve-merges, to pass along git rebase if --rebase is in affect.

ACK!

> Also add a new pull.preserve-merges config setting, to enable this
> behavior as the default.

This should probably be added to config.txt and Documentation/git-pull.txt, too, right?

FYI I started to rewrite the complete --preserve-merges support for the interactive rebase some time ago, based on the experience of the merging rebases:

	https://github.com/msysgit/git/commit/b733454b

(part of the rebase-i-p branch). The idea is to use the 'exec' command of the interactive rebase to do a much better job, and to allow reordering (and in particular fixup commits) even when trying to preserve merges.

Unfortunately, the resulting branches look slightly differently now, breaking the (horribly complicated -- my fault!) unit tests, and due to an utter lack of time I had to stall that project.

Feel free to play with it if you want!

Ciao, Johannes