On Mon, Sep 12, 2011 at 11:13:37PM -0400, Jay Soffian wrote: > So my approach is to create a temporary, empty, workdir, using > symlinks to point to the parent repo per git new-workdir. > > I then invoke merge-recursive directly inside the temporary workdir. > > The question is whether this is safe to do, or whether merge-recursive > expects a fully populated working tree that matches the index. My easy > test cases seem to work correctly, but I'm concerned that I sometimes > get: I'm not sure if we were ever using merge-recursive like that. Especially with Elijah's latest patches to handle worktree dirtiness better, I wouldn't be surprised if it has issues. What we do now at GitHub is something like: export GIT_WORK_TREE=/some/tmpdir export GIT_INDEX_FILE=/some/tmpfile git read-tree -i -m --aggressive $merge_base $us $them git merge-index git-merge-one-file -a I also have a patch to do the content-level merge in read-tree without touching the filesystem at all. But we're not using it yet, and I should probably write more tests for it. You can see it at: git://github.com/peff/git.git jk/read-tree-content-merge It should produce the same results as the snippet above, but faster. Both of those will obviously not handle renames or do recursive merges like merge-recursive, of course. -Peff -- 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