On Wed, 19 Mar 2008, John Goerzen wrote: > > ####### > # Set up bug #2 > > jgoerzen@katherina:/tmp/testrepo$ echo foo > foo > jgoerzen@katherina:/tmp/testrepo$ git add foo > jgoerzen@katherina:/tmp/testrepo$ git commit -m 'Added foo' > jgoerzen@katherina:/tmp/testrepo$ git checkout testbranch > Switched to branch "testbranch" > jgoerzen@katherina:/tmp/testrepo$ ls -l > total 0 > lrwxrwxrwx 1 jgoerzen jgoerzen 16 Mar 19 18:14 files -> /tmp/nonexistant > drwxr-xr-x 2 jgoerzen jgoerzen 22 Mar 19 18:14 files.upstream > jgoerzen@katherina:/tmp/testrepo$ git merge master > fatal: Entry 'files/delete.me' would be overwritten by merge. Cannot merge. > Merge with strategy recursive failed. Ok, so if I read this right, you have a D/F conflict, with the current branch having a file (or rather, a symlink) called "files", and the branch you are trying to merge has a *directory* called "files" in it, and the merge gets really unhappy about that conflict. Now, arguably, it should just see them as two independent issues, and then the rename detection will notice that the "files/delete.me" file got renamed as "files.upstream/delete.me", so *after* rename detection there will be no D/F conflict in the end result, but we see the conflict before that all even happens. Ho humm. With the new unpack-trees logic it's pretty easy to *not* unpack with DF conflicts (add a flag that tells us to use "base_name_compare()" instead of "df_name_compare()" in do_compare_entry()), and maybe we can then make builtin-merge-recursive.c set that flag. But then builtin-merge-recursive would also have to understand about D/F conflicts itself (since now unpack_trees() wouldn't give them as conflicts any more). Linus -- 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
