Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > ... especially since I hope that we have them builtin soon, and not only > that, but have builtin-merge call them as C functions, not with fork() and > exec(). Because builtin-merge.c does not directly use fork/exec but uses run_command() interface, non POSIX platforms can spawn subprocesses just fine, can't they? I do not think at this point it is of any high priority to call strategies internally, avoiding fork/exec. We may apply hundreds of patches per minute, but would fork/exec overhead matter for merges? Especially because some strategies (recursive and perhaps the rumored "blame" even more so) are quite data intensive operations, libifying them is not worth it, compared to the nice isolation between processes we get from running them as a separate program. We get the necessary clean-up after strategy did its thing for almost free (well, "at the cost of fork/exec"). -- 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
