> [1] seems to solve this with some fairly complex cherry-picking and > ancestry manipulation that, admittedly, I don't quite understand, but > it seems like it might be able to bring along a merge's multiple > parents information throughout the rebase and maintain the merge as a > single, non-flattened merge commit. Hm. Sorry for the noise about that Mercurial link--mostly talking to myself now, but I've discovered `git rebase -i -p` does exactly what I want (I think). Is there a reason the "preserve merge" option in the git-rebase--interactive isn't also in the non-interactive git-rebase that is invoked by a git pull --rebase? I noticed the t3400.sh test explicitly tests for the flattening behavior, but I can't tell if that is because it's testing for explicitly desired behavior or if the "linear-izing" is something that is up for debate (or a command line/config option). Would it be foolish for me to work on something like this? I can probably hold my own at copy/pasting around in the shell scripts. Thanks, Stephen -- 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
