Hi, On Tue, Mar 17, 2015 at 12:49 AM, Yurii Shevtsov <ungetch@xxxxxxxxx> wrote: > I'm going to write for this idea. As I know good proposal should > contain timeline and Todo estimations. What should I write in my > proposal, since there is no clear plan for converting scripts to > builtins. Thanks in advance! I'm actually writing a proposal for the same topic because I somehow ended up with a working prototype of git-pull.c while exploring the internal git API ;). It's not ready as a patch yet though as there are some problems with git's internal API which causes e.g. double free errors and too much code complexity due to required functionality not being exposed by builtins, which will have to be addressed. Generally, it would be easy to convert any shell script to C by just using the run_command* functions (and in less lines of code), but that would not be taking advantage of the potential benefits in porting shell scripts to C. To summarize the (ideal) requirements: * zero spawning of processes so that the internal object/config/index cache can be taken advantage of. (and to avoid the process spawning overhead which is relative large in e.g. Windows) * avoid needless parsing since we have direct access to the C data structures. * use the internal API as much as possible: share code between the builtins (e.g. fmt-merge-msg.c, exposed in fmt-merge-msg.h) in order to reduce code complexity. The biggest wins would definitely be portability, but there may be performance improvements, though they are theoretical at this point. I'm not exactly sure if the above requirements are sane, which is why I'm also CC-ing Dscho who knows the problems of git on Windows more than I do. Regards, Paul -- 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