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 to happen as well). I
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
following behaviour:
Tha
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 narrowing this down!
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 since --preserve-merges f
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 pro
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
6 matches
Mail list logo