Thread (4 messages) flat view 4 messages, 4 authors, 2016-06-15

Re: [GSoC] Applying for conversion scripts to builtins

From: Paul Tan <hidden>
Date: 2016-06-15 23:04:10

Hi,

On Tue, Mar 17, 2015 at 12:49 AM, Yurii Shevtsov [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help