Re: Odd rebase behavior

On Fri, Dec 18, 2015 at 06:05:49PM +, John Keeping wrote: > On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote: > > John Keeping writes: > > > > > It seems that the problem is introduces by --preserve-merges (and > > > -Xsubtree causes something interesting

Re: Odd rebase behavior

John Keeping writes: > It seems that the problem is introduces by --preserve-merges (and > -Xsubtree causes something interesting to happen as well). I see the > following behaviour: Thanks for narrowing this down! Is it possible this is actually a cherry-pick problem

Re: Odd rebase behavior

On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote: > John Keeping writes: > > > It seems that the problem is introduces by --preserve-merges (and > > -Xsubtree causes something interesting to happen as well). I see the > > following behaviour: > > Thanks for

Re: Odd rebase behavior

Am 18.12.2015 um 19:05 schrieb John Keeping: On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote: John Keeping writes: It seems that the problem is introduces by --preserve-merges (and -Xsubtree causes something interesting to happen as well). I see the

Re: Odd rebase behavior

On Tue, Dec 15, 2015 at 09:17:30PM -0600, David A. Greene wrote: > According to the rebase man page, rebase gathers commits as in "git log > ..HEAD." However, that is not what happens in the tests > below. Some of the commits disappear. > > The test basically does this: > > - Setup a master

Odd rebase behavior

Hi, The attached tests do not do what I expected them to do. I commented out the tests involving the new rebase empty commit behavior I just sent. The uncommented tests show the strange behavior. According to the rebase man page, rebase gathers commits as in "git log ..HEAD." However, that is