On Mon, Jan 25, 2010, Johannes Schindelin wrote: > On Fri, 22 Jan 2010, Alex Scarborough wrote: > > > Previously, rebase -p would not preserve a merge commit if the merge > > could be resolved as a fast-forward. rebase -p now passes --no-ff to > > git merge when recreating a merge commit, which ensures that merge > > commits created with git merge --no-ff are preserved. > > For my use case (well, it used to be my use case), namely keeping a number > of topic branches on top of an upstream up-to-date, this is not the > desired action. In my use case, merged topic branches should just vanish, > and not even leave a merge commit. I see. In that use case this patch would be rather irritating :) What do you think of adding a --no-ff option to git rebase which, when used with -p, will recreate merge commits even if they could be resolved as a fast-forward? That would leave your use case unchanged while giving my use case a way out, so to speak. Either way, I suggest we change the documentation for rebase -p to state that it does not preserve merge commits that can be fast-forwarded after rebasing. If it sounds good, I should be able to roll some patches by the end of the week. -Alex Scarborough -- 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