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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html