bug in merge

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