Re: problem with cherry-picking a commit which comes before introducing a new submodule

(+cc: Elijah Newren, who has worked on some of this code)

Yaroslav Halchenko wrote:

In our repository we had some submodules, then there was a branch off
(call new branch todonotloose) with a single commit.  In the master we
had some other commits and moved one of the subdirectories into a
submodule.

Later on we decided to cherry pick todonotloose into master but
cherry-pick fails despite the fact that 'git show todonotloose | patch
-p1' applies just fine, ie there were no changes touching any of the
submodules.

[...]

$> git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	new file:   poster-hbm2011_neurodebian/abstract.txt
#	modified:   poster-hbm2011_neurodebian/jb.txt
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#	added by us:        frontiers/code
#

As contrib/examples/git-revert.sh explains, the heart of "git
cherry-pick" is

	base=todonotloose^
	next=todonotloose
	head=HEAD

	git merge-recursive $base -- $head $next

Could you try that, perhaps with GIT_MERGE_VERBOSITY=4 (or some other
number from 1 to 5, larger is louder) in the environment?  For context,

	git ls-files -u;	# after the merge
	git diff-tree todonotloose
	git diff-tree todonotloose^ HEAD

would also be interesting.