Re: [GSoC] Applying for conversion scripts to builtins

From: Paul Tan <pyokagan@gmail.com>
Date: Mar 17, 2015, 00:22 UTC
Message-ID: <CACRoPnQDopKNW2oc=UiLhupBBSh5ZmUHR7hU5aeguD4OVd1uPQ@mail.gmail.com>
In-Reply-To: <CAHLaBNJkL1CUJEk=cH=CLcDvZtoAr+PiCo2KHjfMLUKsugtRPA@mail.gmail.com>

Hi,

On Tue, Mar 17, 2015 at 12:49 AM, Yurii Shevtsov <ungetch@gmail.com> 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