I've fixed up merge-recursive not to warn "working file will be clobbered" when unneeded, and merged it to "next" tonight. This is a usability fix but if done incorrectly we can break a safety valve. The "next" version changes behaviour from the traditional one when (1) paths that are untracked in our branch exists in the common ancestor and the other branch we merge into our branch, (2) the other branch did not make any changes to these paths, and (3) the working tree has these paths as untracked files. Under this condition, 3-way merge decides the path should not exist in the result. This has not been changed (and shouldn't be). But what is being fixed is what "should not exist" means. We used to say "we have that path in our working tree, which will be lost by the merge, so we won't merge". Which was perhaps safer but was inconvenient. The corrected behaviour should be "the path is not tracked in our branch, and the result of the merge won't have it tracked either, and we will leave those untracked working tree files as they were". I added a handful tests to t6022 to catch potential breakages, and the code still passes them, but that does not mean it is perfect. If the program refuses to proceed when it can, you found a safer breakage I do not worry too much about. If the program overwrites or loses an untracked working tree file as a result of the merge, then that means the updated merge-recursive relaxed the check too much. So please handle this with a bit of extra care than usual; I'd appreciate extra sets of eyeballs to sanity check. - 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