[Michael, sorry for the double mail -- I typoed the list address on the first round.] I recently looked into making merge-recursive more useful as a modular piece in various tasks, e.g. Michael's git-imerge and the experiments I made in showing evil merges. This miniseries is the extremely low-hanging fruit. If it makes a good first step for git-imerge, perhaps it can go in like this. It's not a big speedup (about 2.2s vs 2.4s in a sample conflicting merge in git.git), but it does feel much cleaner to avoid touching the worktree unless actually necessary. Otherwise it's probably not worth it just yet; for what I want to do with it, we need some more reshuffling of things. Thomas Rast (3): merge-recursive: remove dead conditional in update_stages() merge-recursive: untangle double meaning of o->call_depth merge-recursive: -Xindex-only to leave worktree unchanged Documentation/merge-strategies.txt | 4 ++++ merge-recursive.c | 46 +++++++++++++++++++++----------------- merge-recursive.h | 1 + t/t3030-merge-recursive.sh | 13 +++++++++++ 4 files changed, 43 insertions(+), 21 deletions(-) -- 1.8.3.2.908.gbd0dbd0 -- 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