[argh, resend, actually remembering to cc the list this time] At GitHub, we're using read-tree, merge-index, and merge-one-file to do trivial content-level merges from bare repositories (without having to check out the entire repository contents each time). However, we noticed a bug in git-merge-one-file when used with GIT_WORK_TREE; it can silently create bogus results that ignore the "theirs" side of files needing content-level merging. The problem is that merge-one-file simply assumes it is in the root of the working tree without any checking. The only two places we use merge-one-file in git itself are in the octopus and resolve strategies. I think normal use is fine, because "git merge" will have changed to the toplevel of the worktree already. So I doubt anybody else is being affected by this. But we do expose the commands for general use, with no disclaimer or check on the working tree status or location. And the resulting bogus merge is a nasty surprise. [1/2]: add tests for merge-index / merge-one-file [2/2]: merge-one-file: fix broken merges with GIT_WORK_TREE -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