Johannes Sixt <j6t@xxxxxxxx> writes: >> Doesn't "checkout --conflict=merge" use the same ll_merge() machinery? > > It does, without setting up .gitattributes, either (IIUC), which is a bug IMO. I don't think there is any bug there; git_checkattr() that is used by git_path_check_merge() autoinitializes the attribute machinery. However, I think you need this fix for "checkout -m" to work as intended, if your custom merge driver has recursive attribute set to 'binary' or something: diff --git a/builtin-checkout.c b/builtin-checkout.c index 64f3a11..50f5079 100644 --- a/builtin-checkout.c +++ b/builtin-checkout.c @@ -167,7 +167,7 @@ static int checkout_merged(int pos, struct checkout *state) fill_mm(active_cache[pos+2]->sha1, &theirs); status = ll_merge(&result_buf, path, &ancestor, - &ours, "ours", &theirs, "theirs", 1); + &ours, "ours", &theirs, "theirs", 0); free(ancestor.ptr); free(ours.ptr); free(theirs.ptr); I don't know why I decided to pass "1" to ll_merge() there; it doesn't make any sense and looks like an untested bug to me. The ll_merge() call jc/cache-unmerge topic adds for "rerere forget" doesn't share this problem. -- 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