All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: John Keeping <john@keeping.me.uk>,
	"David A. Greene" <greened@obbligato.org>
Cc: git@vger.kernel.org, sandals@crustytoothpaste.net, peff@peff.net,
	gitster@pobox.com
Subject: Re: Odd rebase behavior
Date: Fri, 18 Dec 2015 22:05:37 +0100	[thread overview]
Message-ID: <56747521.9090701@kdbg.org> (raw)
In-Reply-To: <20151218180549.GA14056@serenity.lan>

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 <john@keeping.me.uk> 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 forces rebase to use
>> cherry-pick?
>
> I'm pretty sure this a result of the code in git-rebase--interactive.sh
> just below the comment "Watch for commits that have been dropped by
> cherry-pick", which filters out certain commits.  However, I'm not at
> all familiar with the --preserve-merges code in git-rebase so I could be
> completely wrong.
>
>>> git rebase -Xsubtree=files_subtree --onto files-master master
>>>
>>> 	fatal: Could not parse object 'b15c4133fc3146e1330c84159886f0f7a09fbf43^'
>>> 	Unknown exit code (128) from command: git-merge-recursive
>>> b15c4133fc3146e1330c84159886f0f7a09fbf43^ -- HEAD
>>> b15c4133fc3146e1330c84159886f0f7a09fbf43
>>
>> Ah, good!  I had seen this behavior as well but couldn't remember what I
>> did to trigger it.
>>
>> I don't think I have the expertise to fix rebase and/or cherry-pick.
>> What's the process for adding these tests to the testbase and marking
>> them so the appropriate person can fix them?  I see a lot of TODO tests.
>> Should I mark these similarly and propose a patch to the testbase?
>
> I think marking them with test_expect_failure (instead of
> test_expect_success) is enough.
>

There are a few known breakages recorded in 
t3512-cherry-pick-submodule.sh. Perhaps the one observed here is already 
among them?

-- Hannes

  reply	other threads:[~2015-12-18 21:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16  3:17 Odd rebase behavior David A. Greene
2015-12-16 22:17 ` John Keeping
2015-12-18 17:43   ` David A. Greene
2015-12-18 18:05     ` John Keeping
2015-12-18 21:05       ` Johannes Sixt [this message]
2015-12-19 16:09       ` John Keeping

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56747521.9090701@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=greened@obbligato.org \
    --cc=john@keeping.me.uk \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.