On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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: >> 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? -- 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
