Re: [GSoC] Convert “git stash” to builtin proposal

[Christian Couder]

On Sun, Mar 25, 2018 at 4:38 PM, Paul-Sebastian Ungureanu
 wrote:
> On 25.03.2018 12:46, Christian Couder wrote:
>>
>> On Sat, Mar 24, 2018 at 8:31 PM, Paul-Sebastian Ungureanu
>>  wrote:
>>>
>>> On 23.03.2018 19:11, Christian Couder wrote:
>>>
> * Ensure that no regression occurred: considering that there are plenty
> of tests and that I have a good understanding of the function, this
> should be a trivial task.

 There are a lot of things that the test suite doesn't test.
>>>
>>> Hopefully, by first adding new tests, any eventual bug will be spotted.
>>
>> I was thinking about things like memory leaks that tests cannot easily
>> spot.>
>
> I will do my best and follow best practices in order to avoid any memory
> leaks. However, to make sure that my code is really leak free, I will use
> Valgrind, which is already integrated with the testing framework.

Yeah, but it's still not so easy even with valgrind for a number of
reasons. For example it's difficult to test all the error paths, and
there are also some memory leaks that we accept when we know that they
happen just once and that we are going to exit soon anyway when we
should free the memory.

>> Ok. Feel free to resend another version of your proposal.
>
> Sorry for not sending the whole proposal again. I decided to send only the
> changed parts because the proposal is quite big and I wanted to avoid
> sending the same thing over and over again.

It's up to you, but but fewer people might review it.

> One thing I did not mention in the previous reply was that I also added a
> new paragraph to "Benefits to community" about 'git stash' being slow on
> Windows for a lot of users. I consider this alone to be a very good
> justification for this project and doing this project will be very
> beneficial for the Windows users.

Sure.

Re: [GSoC] Convert “git stash” to builtin proposal

[Johannes Schindelin]

Hi Paul,

On Sun, 25 Mar 2018, Paul-Sebastian Ungureanu wrote:

> One thing I did not mention in the previous reply was that I also added
> a new paragraph to "Benefits to community" about 'git stash' being slow
> on Windows for a lot of users. I consider this alone to be a very good
> justification for this project and doing this project will be very
> beneficial for the Windows users.

Yes!

Thank you,
Johannes

Re: [GSoC] Convert “git stash” to builtin proposal

[Paul-Sebastian Ungureanu]

On 25.03.2018 12:46, Christian Couder wrote:

On Sat, Mar 24, 2018 at 8:31 PM, Paul-Sebastian Ungureanu
 wrote:

On 23.03.2018 19:11, Christian Couder wrote:


* Ensure that no regression occurred: considering that there are plenty
of tests and that I have a good understanding of the function, this
should be a trivial task.


There are a lot of things that the test suite doesn't test.


Hopefully, by first adding new tests, any eventual bug will be spotted.


I was thinking about things like memory leaks that tests cannot easily spot.> 


I will do my best and follow best practices in order to avoid any memory 
leaks. However, to make sure that my code is really leak free, I will 
use Valgrind, which is already integrated with the testing framework.



Ok. Feel free to resend another version of your proposal.
Sorry for not sending the whole proposal again. I decided to send only 
the changed parts because the proposal is quite big and I wanted to 
avoid sending the same thing over and over again.


One thing I did not mention in the previous reply was that I also added 
a new paragraph to "Benefits to community" about 'git stash' being slow 
on Windows for a lot of users. I consider this alone to be a very good 
justification for this project and doing this project will be very 
beneficial for the Windows users.


Best regards,
Paul Ungureanu

Re: [GSoC] Convert “git stash” to builtin proposal

[Paul-Sebastian Ungureanu]

On 23.03.2018 19:06, Johannes Schindelin wrote:

[... proposal ...]


This is a pretty good proposal. The initial draft at converting `stash
list` is a good start (it will need to be converted to avoid spawning an
extra process, but that is something we can do incrementally, together).


Thank you for your kind words. It feels good to see other people 
appreciate my work. It is a strong incentive to keep going on. I made a 
few adjustments and I hope that the final version will be better.


Best regards,
Paul Ungureanu

Re: [GSoC] Convert “git stash” to builtin proposal

[Christian Couder]

On Sat, Mar 24, 2018 at 8:31 PM, Paul-Sebastian Ungureanu
 wrote:
> On 23.03.2018 19:11, Christian Couder wrote:
>
>>> * Ensure that no regression occurred: considering that there are plenty
>>> of tests and that I have a good understanding of the function, this
>>> should be a trivial task.
>>
>> There are a lot of things that the test suite doesn't test.
>
> Hopefully, by first adding new tests, any eventual bug will be spotted.

I was thinking about things like memory leaks that tests cannot easily spot.

>>> * In the end, an analysis based on performance can be made.
>>> Benchmarking the script will be done by recording the running time
>>> given a large set of diversified tests that cover all the
>>> functionalities, before and after conversion. The new commands should
>>> run faster just because they were written in C, but I expect to see
>>> even more improvements.
>>
>> If you want to do benchmarks, you might want to add performance tests
>> into t/perf.
>
> That is great. I will surely make use of the existent testing framework to
> do benchmarks.

Good.

>>> ## Example of conversion (for “git stash list”)
>>> --
>>> To test my capabilities and to be sure that I am able to work on a
>>> project of this kind, I tried to convert “git stash list” into a built-
>>> in. The result can be found below in text-only version or at the Github
>>> link.
>>
>> I think it would be better if it was sent as a patch (maybe an RFC
>> patch) to the mailing list and add the link to the patch email in the
>> maling list archive to your proposal.
>
> I sent it as a [RFC] patch to the mailing list and included it in the
> proposal.
>
> 

Nice.

>> It could be useful if you described a bit more how you could (re)use
>> the work that has already been made.
>>
>> In the rest of your proposal it looks like you are starting from
>> scratch, which is a bit strange if a lot of progress has already been
>> made.
>
> The patches about converting ‘git stash’ are a great starting point and I
> will definitely use them. Each time I start converting a new command I will
> first take a look at what other patches there are, evaluate them and if I
> consider the patch to be good enough I will continue my work on top of that
> patch. Otherwise, I will start from scratch and that patch will only serve
> for comparison.
>
> One other resource that is of great importance is git itself. I can learn
> how a builtin is structured and how it is built by considering examples the
> other Git commands. Having a similar coding standard used, the codebase will
> be homogeneous and hopefully easier to maintain.
>
> Another important resource are commands that are Google Summer of Code
> projects from previous years (2016 and 2017) which had as purpose to convert
> “git bisect” and “git submodule”. I can always take a look at the patches
> they submitted and read their code reviews to avoid making same mistakes
> they did.

Nice.

>> It is probably better especially for reviewers and more common to work
>> in small batches, for example to send a patch series converting a few
>> related commands, then to start working on the next small batch of
>> commands in another patch series while improving the first patch
>> series according to reviews.
>>
>> Also we ask GSoC students to communicate publicly every week about
>> their project for example by writing a blg post or sending a report to
>> the mailing list.
>
> Noted.
>
>>> ## Git contributions
>>> --
>>> My first contribution to Git was to help making “git tag --contains
>>> ” les chatty if  is invalid. Looking over the list of available
>>> microprojects, there were a couple of microprojects which got my
>>> attention, but I picked this up because it seemed to be a long-standing
>>> bug (I noticed it was approached by students in 2016, 2017 and now in
>>> 2018). Thanks to the code reviews from the mailing list, after a few
>>> iterations I succeeded in coming up with a patch that not only fixed
>>> the mentioned problem, but also a few others that were having the same
>>> cause.
>>>
>>> It got merged in the proposed updates branch.
>>
>> What is its status in Junio's "What's cooking in Git" emails?
>
> It is now in the ‘next’ branch of the Git repository.
>
> I updated the proposal, in which I included these ideas and some additional
> examples. Thank you a lot!

Ok. Feel free to resend another version of your proposal.

Thanks.

Re: [GSoC] Convert “git stash” to builtin proposal

[Paul-Sebastian Ungureanu]

On 23.03.2018 19:11, Christian Couder wrote:


* Ensure that no regression occurred: considering that there are plenty
of tests and that I have a good understanding of the function, this
should be a trivial task.


There are a lot of things that the test suite doesn't test.


Hopefully, by first adding new tests, any eventual bug will be spotted.


* In the end, an analysis based on performance can be made.
Benchmarking the script will be done by recording the running time
given a large set of diversified tests that cover all the
functionalities, before and after conversion. The new commands should
run faster just because they were written in C, but I expect to see
even more improvements.


If you want to do benchmarks, you might want to add performance tests
into t/perf.


That is great. I will surely make use of the existent testing framework 
to do benchmarks.



## Example of conversion (for “git stash list”)
--
To test my capabilities and to be sure that I am able to work on a
project of this kind, I tried to convert “git stash list” into a built-
in. The result can be found below in text-only version or at the Github
link.


I think it would be better if it was sent as a patch (maybe an RFC
patch) to the mailing list and add the link to the patch email in the
maling list archive to your proposal.


I sent it as a [RFC] patch to the mailing list and included it in the 
proposal.





It could be useful if you described a bit more how you could (re)use
the work that has already been made.

In the rest of your proposal it looks like you are starting from
scratch, which is a bit strange if a lot of progress has already been
made.


The patches about converting ‘git stash’ are a great starting point and 
I will definitely use them. Each time I start converting a new command I 
will first take a look at what other patches there are, evaluate them 
and if I consider the patch to be good enough I will continue my work on 
top of that patch. Otherwise, I will start from scratch and that patch 
will only serve for comparison.


One other resource that is of great importance is git itself. I can 
learn how a builtin is structured and how it is built by considering 
examples the other Git commands. Having a similar coding standard used, 
the codebase will be homogeneous and hopefully easier to maintain.


Another important resource are commands that are Google Summer of Code 
projects from previous years (2016 and 2017) which had as purpose to 
convert “git bisect” and “git submodule”. I can always take a look at 
the patches they submitted and read their code reviews to avoid making 
same mistakes they did.



It is probably better especially for reviewers and more common to work
in small batches, for example to send a patch series converting a few
related commands, then to start working on the next small batch of
commands in another patch series while improving the first patch
series according to reviews.

Also we ask GSoC students to communicate publicly every week about
their project for example by writing a blg post or sending a report to
the mailing list.


Noted.


## Git contributions
--
My first contribution to Git was to help making “git tag --contains
” les chatty if  is invalid. Looking over the list of available
microprojects, there were a couple of microprojects which got my
attention, but I picked this up because it seemed to be a long-standing
bug (I noticed it was approached by students in 2016, 2017 and now in
2018). Thanks to the code reviews from the mailing list, after a few
iterations I succeeded in coming up with a patch that not only fixed
the mentioned problem, but also a few others that were having the same
cause.

It got merged in the proposed updates branch.


What is its status in Junio's "What's cooking in Git" emails?


It is now in the ‘next’ branch of the Git repository.

I updated the proposal, in which I included these ideas and some 
additional examples. Thank you a lot!


Best regards,
Paul Ungureanu

Re: [GSoC] Convert “git stash” to builtin proposal

[Christian Couder]

On Fri, Mar 23, 2018 at 12:15 AM, Paul-Sebastian Ungureanu
 wrote:
>
> On Tue, 2018-03-20 at 23:08 +0100, Christian Couder wrote:
>>
>> On Tue, Mar 20, 2018 at 9:09 PM, Paul-Sebastian Ungureanu
>>  wrote:
>> >
>> > * Convert function: this step is basically makes up the goal of
>> > this
>> > project.
>>
>> Could you explain a bit more how you would convert a function? Or
>> could you explain for example how you would convert "git stash list"
>> below?
>
> In order to convert a command, all the functions which are used by the
> command must be converted first. The conversion will start with the
> bottom-level functions, which do not have any dependencies.
>
> For example, to convert "git stash list", the parser will call
> “list_stash”, which will call “have_stash”. The conversion of these
> functions will be made in reverse order they were mentioned (have_stash
> first and then list_stash).

Ok.

> It is very important to know the Git source well in order to avoid
> reimplementing functionality. In this case “have_stash()” is somehow
> already implemented as “get_oid(ref_stash, )”.
>
>> > I am expecting to submit a patch for every command that is
>> > converted.
>> > This way, I have well set milestones and results will be seen as
>> > soon
>> > as possible. Moreover, seeing my contributions getting merged will
>> > be a
>> > huge confidence boost to myself.
>> > Each “convert” phase of the project below is not only about
>> > converting
>> > from Shell to C, but also ensuring that everything is documented,
>> > there
>> > are enough tests and there are no regressions.
>> >
>> > 14th May - 20th May - Convert "git stash list"
>>
>> For example could you explain a bit more which functions/commands you
>> would create in which file and how you would call them to convert
>> `git
>> stash list`
>
> The new C code will be found in stash-helper.c and will be used by git-
> stash.sh until the full conversion is complete. As soon as the entire
> conversion is done, stash-helper.c will be promoted to stash.c. Any
> functionality that will be implemented, but is not strictly related to
> git stash will reside in the appropriate files (for example if I had to
> implement similar to get_oid, which is not related to git stash, but to
> Git, then I would not implement it in stash-helper.c; anyway, I do not
> believe I will encounter this situation that often).

Ok.

> In the updated version of the proposal [1], I included the ideas stated
> before and more information about the procces of benchmarking. In
> addition, to test my capabilities and to be sure that I am able to work
> on a project of this kind, I tried to convert “git stash list” into a
> built-in (the code can be found in proposal).
>
> [1] https://docs.google.com/document/d/1TtdD7zgUsEOszHG5HX1at4zHMDsPmSB
> YWqydOPTTpV8/edit

I guess that below you inlined the updated version of your proposal. Nice.

> Convert “git stash” to builtin

[...]

> * Ensure that no regression occurred: considering that there are plenty
> of tests and that I have a good understanding of the function, this
> should be a trivial task.

There are a lot of things that the test suite doesn't test.

> * Write more tests to ensure the best code coverage. This step will be
> almost non existent due to step 4.

Maybe you should use a numbered list if you want to refer to the items
by their number.

> * In the end, an analysis based on performance can be made.
> Benchmarking the script will be done by recording the running time
> given a large set of diversified tests that cover all the
> functionalities, before and after conversion. The new commands should
> run faster just because they were written in C, but I expect to see
> even more improvements.

If you want to do benchmarks, you might want to add performance tests
into t/perf.

[...]

> ## Example of conversion (for “git stash list”)
> --
> To test my capabilities and to be sure that I am able to work on a
> project of this kind, I tried to convert “git stash list” into a built-
> in. The result can be found below in text-only version or at the Github
> link.

I think it would be better if it was sent as a patch (maybe an RFC
patch) to the mailing list and add the link to the patch email in the
maling list archive to your proposal.

[...]

> Useful resources
> There has been a lot of progress made in this direction already and I
> believe it will serve of great help. However, from my understanding it
> is not yet mergeable and it requires changes.
>
> https://public-inbox.org/git/20170608005535.13080-1-j...@teichroeb.net/
> T/#m8849c7ce0ad8516cc206dd6910b79591bf9b3acd

It could be useful if you described a bit more how you could (re)use
the work that has already been made.

In the rest of your proposal it looks like you are starting from
scratch, which is a bit strange if a lot of progress has already been
made.

Re: [GSoC] Convert “git stash” to builtin proposal

[Johannes Schindelin]

Hi Paul-Sebastian,

On Fri, 23 Mar 2018, Paul-Sebastian Ungureanu wrote:

> On Tue, 2018-03-20 at 23:08 +0100, Christian Couder wrote:
> > Hi,
> > 
> > On Tue, Mar 20, 2018 at 9:09 PM, Paul-Sebastian Ungureanu
> >  wrote:
> > > 
> > > * Convert function: this step is basically makes up the goal of
> > > this
> > > project.
> > 
> > Could you explain a bit more how you would convert a function? Or
> > could you explain for example how you would convert "git stash list"
> > below?
> 
> In order to convert a command, all the functions which are used by the
> command must be converted first. The conversion will start with the
> bottom-level functions, which do not have any dependencies.
> 
> For example, to convert "git stash list", the parser will call
> “list_stash”, which will call “have_stash”. The conversion of these
> functions will be made in reverse order they were mentioned (have_stash
> first and then list_stash).
> 
> It is very important to know the Git source well in order to avoid
> reimplementing functionality. In this case “have_stash()” is somehow
> already implemented as “get_oid(ref_stash, )”. 

Very good

> [... proposal ...]

This is a pretty good proposal. The initial draft at converting `stash
list` is a good start (it will need to be converted to avoid spawning an
extra process, but that is something we can do incrementally, together).

Ciao,
Johannes

Re: [GSoC] Convert “git stash” to builtin proposal

[Paul-Sebastian Ungureanu]

Hello,

On Tue, 2018-03-20 at 23:08 +0100, Christian Couder wrote:
> Hi,
> 
> On Tue, Mar 20, 2018 at 9:09 PM, Paul-Sebastian Ungureanu
>  wrote:
> > 
> > * Convert function: this step is basically makes up the goal of
> > this
> > project.
> 
> Could you explain a bit more how you would convert a function? Or
> could you explain for example how you would convert "git stash list"
> below?

In order to convert a command, all the functions which are used by the
command must be converted first. The conversion will start with the
bottom-level functions, which do not have any dependencies.

For example, to convert "git stash list", the parser will call
“list_stash”, which will call “have_stash”. The conversion of these
functions will be made in reverse order they were mentioned (have_stash
first and then list_stash).

It is very important to know the Git source well in order to avoid
reimplementing functionality. In this case “have_stash()” is somehow
already implemented as “get_oid(ref_stash, )”. 

> > I am expecting to submit a patch for every command that is
> > converted.
> > This way, I have well set milestones and results will be seen as
> > soon
> > as possible. Moreover, seeing my contributions getting merged will
> > be a
> > huge confidence boost to myself.
> > Each “convert” phase of the project below is not only about
> > converting
> > from Shell to C, but also ensuring that everything is documented,
> > there
> > are enough tests and there are no regressions.
> > 
> > 14th May - 20th May - Convert "git stash list"
> 
> For example could you explain a bit more which functions/commands you
> would create in which file and how you would call them to convert
> `git
> stash list`

The new C code will be found in stash-helper.c and will be used by git-
stash.sh until the full conversion is complete. As soon as the entire
conversion is done, stash-helper.c will be promoted to stash.c. Any
functionality that will be implemented, but is not strictly related to
git stash will reside in the appropriate files (for example if I had to
implement similar to get_oid, which is not related to git stash, but to
Git, then I would not implement it in stash-helper.c; anyway, I do not
believe I will encounter this situation that often).

In the updated version of the proposal [1], I included the ideas stated
before and more information about the procces of benchmarking. In
addition, to test my capabilities and to be sure that I am able to work
on a project of this kind, I tried to convert “git stash list” into a
built-in (the code can be found in proposal). 

[1] https://docs.google.com/document/d/1TtdD7zgUsEOszHG5HX1at4zHMDsPmSB
YWqydOPTTpV8/edit

Convert “git stash” to builtin

## Name and Contact Information
--
Hello! My name is Paul-Sebastian Ungureanu. I am currently a first year
Computer Science & Engineering student at Politehnica University of
Bucharest, Romania.

My email address is ungureanupaulsebast...@gmail.com and my phone
number is [CENSORED]. You can also find me on #git IRC channel as
ungps.

FLOSS manual recommends students to include in their proposal their
postal address and mention a relative as a emergency contact. My
permanent address is [CENSORED]. In case of an emergency, you may
contact my brother, [CENSORED] by email at [CENSORED] or by phone at
[CENSORED].

## Synopsis
--
Currently, many components of Git are still in the form of Shell or
Perl scripts. This choice makes sense especially when considering how
faster new features can be implemented in Shell and Perl scripts,
rather than writing them in C. However, in production, where Git runs
daily on millions of computers with distinct configurations (i.e.
different operating systems) some problems appear (i.e. POSIX-to-
Windows path conversion issues).

The idea of this project is to take “git-stash.sh” and reimplement it
in C. Apart from fixing compatibility issues and increasing the
performance by going one step closer to native code, I believe this is
an excellent excuse to fix long-standing bugs or implement new minor
features.

## Benefits to community
--
The essential benefit brought by rewriting Git commands is the
increased compatibility with a large number computers with distinct
configuration. I believe that this project can have a positive impact
on a large mass of developers around the world. By rewriting the code
behind some popular commands and making them “built-in”, developers
will have a better overall experience when using Git and get to focus
on what really matters to them.

As a side effect, there will be a number of other improvements:
increased performance, ability to rethink the design of some code that
suffered from patching along the time, have the chance to create new
features and fix old bugs.

In theory, switching from Bash or Shell scripts, Git will 

Re: [GSoC] Convert “git stash” to builtin proposal

[Christian Couder]

Hi,

On Tue, Mar 20, 2018 at 9:09 PM, Paul-Sebastian Ungureanu
 wrote:
>
> * Convert function: this step is basically makes up the goal of this
> project.

Could you explain a bit more how you would convert a function? Or
could you explain for example how you would convert "git stash list"
below?

> * Ensure that no regression occurred: considering that there are plenty
> of tests and that I have a good understanding of the function, this
> should be a trivial task.
>
> * Finally write more tests to ensure best code coverage.

Maybe, as Dscho suggested to another potential GSoC student, it would
be better to write more tests before converting the function.

> # Useful resources
> There has been a lot of progress made in this direction already and I
> believe it will serve of great help. However, from my understanding it
> is not yet mergeable and it requires changes.
>
> https://public-inbox.org/git/20170608005535.13080-1-j...@teichroeb.net/
> T/#m8849c7ce0ad8516cc206dd6910b79591bf9b3acd

Maybe you should Cc the author of this patch series.

Also please notice that the patch series started with adding some tests.

> I am expecting to submit a patch for every command that is converted.
> This way, I have well set milestones and results will be seen as soon
> as possible. Moreover, seeing my contributions getting merged will be a
> huge confidence boost to myself.

> Each “convert” phase of the project below is not only about converting
> from Shell to C, but also ensuring that everything is documented, there
> are enough tests and there are no regressions.
>
> 14th May - 20th May - Convert "git stash list"

For example could you explain a bit more which functions/commands you
would create in which file and how you would call them to convert `git
stash list`

[GSoC] Convert “git stash” to builtin proposal

[Paul-Sebastian Ungureanu]

Hello,

I have completed the first draft of my proposal for the Google Summer
of Code, which can be found at [1] or below for those who prefer the
text version.

Any feedback is greatly appreciated. Thanks!

[1]
https://docs.google.com/document/d/1TtdD7zgUsEOszHG5HX1at4zHMDsPmSBYWqy
dOPTTpV8/edit?usp=sharing

Best regards,
Paul-Sebastian Ungureanu

# Convert “git stash” to builtin

# Name and Contact Information
Hello! My name is Paul-Sebastian Ungureanu. I am currently a first year
Computer Science & Engineering student at Politehnica University of
Bucharest, Romania.

My email address is ungureanupaulsebast...@gmail.com and my phone
number is [CENSORED]. You can also find me on #git IRC channel as
ungps.

FLOSS manual recommends students to include in their proposal their
postal address and mention a relative as a emergency contact. My
permanent address is [CENSORED]. In case of an emergency, you may
contact my brother, [CENSORED] by email at [CENSORED] or by phone at
[CENSORED].

# Synopsis
Currently, many components of Git are still in the form of Shell or
Perl scripts. This choice makes sense especially when considering how
faster new features can be implemented in Shell and Perl scripts,
rather than writing them in C. However, in production, where Git runs
daily on millions of computers with distinct configurations (i.e.
different operating systems) some problems appear (i.e. POSIX-to-
Windows path conversion issues).

The idea of this project is to take “git-stash.sh” and reimplement it
in C. Apart from fixing compatibility issues and increasing the
performance by going one step closer to native code, I believe this is
an excellent excuse to fix long-standing bugs or implement new minor
features.

# Benefits to community
The essential benefit brought by rewriting Git commands is the
increased compatibility with a large number computers with distinct
configuration. I believe that this project can have a positive impact
on a large mass of developers around the world. By rewriting the code
behind some popular commands and making them “built-in”, developers
will have a better overall experience when using Git and get to focus
on what really matters to them.

As a side effect, there will be a number of other improvements:
increased performance, ability to rethink the design of some code that
suffered from patching along the time, have the chance to create new
features and fix old bugs.

In theory, switching from Bash or Shell scripts, Git will be one step
closer to native code which should have a positive impact on the
performance. Being able to start from a clean slate is a great
opportunity to rethink old designs that may have been patched a lot
during their lifetime. This way, with the help of my mentors, I can
think of new ways to try and remove some limitations of the current
system (if there are any).

Moreover, I believe that the community will benefit greatly from new
features and bug fixes that I could help with. Even though this is not
really one of the main goals of this project, I believe that it would
be easier to fix bugs or implement new features while rewriting the
code. However, I will have to discuss with my mentors and carefully
review issues as I would not want to divagate from the purpose of the
project.

As a last point, I believe it is good to have a more homogenous
codebase, where the majority of the code would be written in C. This
could increase the number of contributions to the project as there are
maybe more programmers who are familiar with C, and not so much with
Perl or shell scripting.

# Deliverables
Deliverable of this project is “git stash” completely rewritten in
portable C code. Along with the new code, there will be some additions
and changes brought to tests to cover any new behaviour.

# Related work
Looking over the list of the other proposed projects, I believe that
“Convert interactive rebase to C” and “git bisect improvements” are the
most alike with this project and may be stretch goal of this project.

Moreover, there is a chance that other scripts could benefit from this
project if it were to be taken as an example for future conversions.

# Biographical information
I am a freshman at Politehnica University of Bucharest, which is
considered to be one of the most prestigious universities in the
Eastern Europe. I consider myself an ambitious software engineer that
enjoys competition. This has been proven by my participation to
programming competitions and extracurricular projects. As much as I
like competitions, I also love working with and meeting people that
share my interests for programming and technology.

Even though, in the last two years I found myself to be more interested
in Android software development rather than competitive programming, I
still take part in most of the competitions, such as contests organized
by Google HashCode, Google KickStart and ACM.

I have a good grasp of programming languages such as C and C++ and I
consider both of them