bug in merge

[Kevin Brannen <kbrannen@corp.hrsmart.com>]

I believe I've just found a bug in "merge", specifically in the 
"recursive" strategy. (Or really, here's another example of and 
hopefully more info on a known bug.) Oh, this is with 1.7.2.3, the 
latest I'm able to use on this machine.

Background:
Over time, code as been developed and commited to our main "dev" branch. 
So the present HEAD was formed by something like 30 commits since the 
last merge. It is not corrupt in any way that I can tell.

We also have a "production" branch, which holds what's approved for 
production. From time to time, we merge "dev" into "production". There 
is no corruption, no unchecked out files, no unmerged files, and not 
even untracked files in the work area. It was totally clean.

Bug:
When I tried to merge dev into production with "git checkout production; 
git merge dev", it would fail:

archive/cgi-bin/admin/addcompany.cgi: unmerged 
(2ea980aa213c6a0bfb0a7e33c8d3fce3af6be91e)
archive/cgi-bin/admin/admineditprofile.cgi: unmerged 
(297a3a7e3229b085061668abd8d5122b48d8d53a)
fatal: git write-tree failed to write a tree

Research:
I had to "git reset --hard" to reset production and try again. After 
googling for this and a few tests, I found that "git merge -s resolve 
dev" was able to successfully merge the code. In looking at the output, 
I think it gives me a clue as to what was failing with the recursive 
strategy.

Trying really trivial in-index merge...
error: Merge requires file-level merging
Nope.
Trying simple merge.
Simple merge failed, trying Automatic merge.
Adding archive/cgi-bin/admin/addcompany.cgi
Adding archive/cgi-bin/admin/admineditprofile.cgi
Merge made by resolve.
  .gitignore                                         |    4 +-
  archive/cgi-bin/{admin => admin/addcompany.cgi}    |    0
...
  rename archive/cgi-bin/{admin => admin/addcompany.cgi} (100%)
  rename {cgi-bin => archive/cgi-bin}/admin/admineditprofile.cgi (100%)

Knowing what happened to the files, I think that I ended up with a 
change tree that recursive just couldn't handle. To the best of my 
knowledge, the changes that happened over time and over multiple 
commits  on dev went something like (each of these being in a different 
commit):

git mv fileA dirX
git mv dirA dirX/fileA
git mv fileB dirX/fileB

So I think the problem is just too many renames/moves of the same object 
and when "recursive" descends the tree, it just can't handle that 
correctly -- or that's my guess. :)

HTH,
Kevin