Re: rebasing merges
- From
Stephen Haberman <stephen@exigencecorp.com>
- Date
- Sep 23, 2008, 04:19 UTC
- Message-ID
- <20080922231927.ef18f420.stephen@exigencecorp.com>
- In-Reply-To
- <20080922155749.c8070681.stephen@exigencecorp.com>
Show 5 quoted lines
> [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