Re: rebase -p confusion in 1.6.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,



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



On Thu, 15 Jan 2009, Sitaram Chamarty wrote:

> On 2009-01-15, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> 
> > The intention was this:
> >
> > 	$ git rebase -p master
> >
> > would need to rewrite _all_ commits that are in "master..".  All of them, 
> > including the merge commits.
> 
> I went hog wild with all sorts of test cases and my head is
> spinning, but -- even when things happen more predictably,
> 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.

Hth,
Dscho

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux