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

[Jonathan Nieder <jrnieder@gmail.com>]

(+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.