Re: [RFC] custom strategies in builtin-merge

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 26, 2008, 01:12 UTC
Message-ID: <7vvdyto3da.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0807260250480.11976@eeepc-johanness>

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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").