Hi Stephen, On Thu, 8 Aug 2013, Stephen Haberman wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html