[BUG] Replacing dir with submodule causes weird issues with cherry-pick

If I replace a directory in my project with a submodule, then later attempt to
cherry-pick a commit that predates this change (but does not touch the directory),
git always marks the submodule path as containing an created/deleted merge conflict.
This makes absolutely no sense, as the change in question has nothing to do with
the directory, but git seems convinced that it did.

% mkdir a b
% cd b
% git init
% touch b && git add b && git commit -m 'initial'
% cd ../a
% git init
% touch a && git add a && git commit -m 'initial'
% mkdir b && touch b/b && git add b/b && git commit -m 'add file b/b'
% git checkout -b test && touch c && git add c && git commit -m 'add file c'
% git checkout master
% git rm -rf b
% git submodule add file://$PWD/../b b
% git commit -m 'replace dir b with submodule'
% # everything is fine at this point
% git cherry-pick test

At this point, the spurious merge conflict exists. Even more annoyingly, if I run
git mergetool, it actually moves the submodule out of the way, which requires manual
repairs after I've aborted the command.

If instead of cherry-pick I run `git show --pretty=email test | git am` everything
works as expected.

This was reproduced using git version 1.7.4.45.g3c41d, built from the next branch.

-Kevin Ballard

Am 2/16/2011 0:19, schrieb Kevin Ballard:

If I replace a directory in my project with a submodule, then later attempt to
cherry-pick a commit that predates this change (but does not touch the directory),
git always marks the submodule path as containing an created/deleted merge conflict.

Known breakage; t3030 tests for it. 7d82b06d talks about a file/directory
conflict, though.

-- Hannes