Re: rebase -p confusion in 1.6.1

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Jan 15, 2009, 18:22 UTC
Message-ID: <slrngmuvn1.7q3.sitaramc@sitaramc.homelinux.net>
In-Reply-To: <alpine.DEB.1.00.0901151751580.3586@pacific.mpi-cbg.de>

On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

> if you would like me to respond to your questions in the future, it is 
> mandatory to keep me in the Cc: list.

OK.  [Is that the list convention too?]

> On Thu, 15 Jan 2009, Sitaram Chamarty wrote:

Show 12 quoted lines

>> I'm unable to make "rebase -p" carry an evil merge over.
>> The "evil" part stays behind.
>> 
>> I'm not sure if that is intentional or not, or (more likely)
>> my brain has become addled and I missed something somewhere.
>
> Yes, this is intentional.
>
> 	Instead of ignoring merges, try to recreate them.
>
> That means it tries to recreate them.  Not that it is successful.  And not 
> even that it realizes when it failed.

Is a conflicted merge that was resolved by making a change that was in neither parent, an evil merge?

Regardless, I suspect rebase -p will not be able to carry such a merge over.

But if it won't carry over the evil in an evil merge, what other uses are there for "rebase -p" as opposed to rebase? Seems to me that the DAG may be different but the tree you end up with is the same then.

I'm sure someone has a blog post or a bookmark or an article or something they wrote long ago about "rebase -i -p". Anyone?