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