From: Stephen Haberman <stephen@exigencecorp.com>
Date: Tue, 23 Sep 2008 04:19:27 GMT
Subject: Re: rebasing merges
Message-ID: <20080922231927.ef18f420.stephen@exigencecorp.com>
In-Reply-To: <20080922155749.c8070681.stephen@exigencecorp.com>


> [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