Re: [GSoC] Applying for conversion scripts to builtins

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 17, 2015, 01:34 UTC
Message-ID: <CACsJy8BrdjNO-3ZFMVjbursTfeWjB0CMPN0-GmNRHFTLdqBvhg@mail.gmail.com>
In-Reply-To: <CACRoPnQDopKNW2oc=UiLhupBBSh5ZmUHR7hU5aeguD4OVd1uPQ@mail.gmail.com>

On Tue, Mar 17, 2015 at 7:22 AM, Paul Tan <pyokagan@gmail.com> wrote:

Show 19 quoted lines

> 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:

While run_command() is not ideal, it would be a good intermediate state where you can verify with the test suite that the C skeleton after rewrite is working ok. Then you can start killing run_command() in subsequent patches. That would be much easier to review code too.

-- 
Duy