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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

<https://public-inbox.org/git/20180324182313.13705-1-ungureanupaulsebastian@xxxxxxxxx>

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
<id>” les chatty if <id> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux