From: Pranit Bauva <pranit.bauva@gmail.com>
To: Git List <git@vger.kernel.org>
Cc: Christian Couder <christian.couder@gmail.com>,
Lars Schneider <larsxschneider@gmail.com>,
Eric Sunshine <sunshine@sunshineco.com>,
Johannes Schindelin <johannes.schindelin@gmx.de>,
Junio C Hamano <gitster@pobox.com>,
Matthieu Moy <matthieu.moy@grenoble-inp.fr>,
Pranit Bauva <pranit.bauva@gmail.com>,
Roberto Tyley <roberto.tyley@gmail.com>
Subject: GSoC Project Selected | Incremental Rewrite of git bisect
Date: Sun, 24 Apr 2016 01:40:27 +0530 [thread overview]
Message-ID: <CAFZEwPMr=imv==kvVULy4PDYKW-0RRQ5a+X8DFqNFhNjCSyWKA@mail.gmail.com> (raw)
Hey everyone,
I am Pranit Bauva studying Mining Engineering at Indian Institute of
Technology, Kharagpur. I have applied for Google Summer of Code 2016
under Git organization and my project[1], "Incremental Rewrite of git
bisect has been selected under the guidance of mentors namely
Christian Couder and Lars Schneider.
Overview of the project:
Git bisect is a frequently used command which helps the developers in
finding the commit which introduced the regression. Some part of it is
written in shell script. I intend to convert it to portable C code
thus making them builtins. This will increase Git’s portability.
A word of thanks:
Firstly I would really like to thank everyone who was involved in
planning GSoC for Git especially my mentors. Also thanking Eric
Sunshine, SZEDER and Junio for patiently reviewing my micro-project
and helping me through that. It was a really great experience. I had
previously no clue about git bisect and have never used it mainly
because I was never involved with maintaining big projects. Posting my
idea to the mailing list (which initially contained a lot of mistakes)
was extremely helpful. Thanks to Christian Couder, Matthieu Moy,
Johannes Schindelin and Stefan Beller for providing useful comments.
Experimenting by converting one function really helped me a lot to
write the proposal. Thanks Roberto for making submitgit.
The subtle hints dropped were the most helpful. Thanks for explaining
those when I could not pick up those hints in the first time.
Status of Micro-project:
I had finalized v14[1] but recently Junio pointed out that the series
requires ordering and restructuring so I will finish with that. I have
my end semester exams going on so I will try to squeeze out some time
in between and try to work on the patches.
Status of the function conversion:
I had attempted to port a function 'check_term_format' from shell to
C. The last version was v3[2]. In the newer version (there only exist
a local copy as I have neither sent it in the mailing list nor I have
pushed it on github) as one test is not exiting properly. The code
written with confusing error handling and return statements which were
mainly there to help me understand "What's happening and where is it
happening?" As requested by Christian, I will still push these changes
to my github fork[3]. Also the function I have written does not use
the API of git as at that time I wasn't quite familiar with it. I am
still not completely familiar with it but I guess that will take some
time.
Status of learning about git plumbing commands:
I have learned about:
- git-check-ref-format
- git-rev-list
- git-rev-parse
The one's left are:
- git-symbolic-refs
- git-show-branch
- git-update-ref
- git-for-each-ref
Status of Week 1 of my proposal:
In my 1st week I was going to set up kcov to test the coverage of
shell scripts as gcov does not cover them. kcov is a lot trickier than
gcov which I hadn't realized it before. I tried to use it in a simple
way but it just wasn't possible for me. So I dug further and found a
patch[5] submitted by Dmitry Vyukov. The linux kernel recently started
using kcov for their coverage and to also find bugs by using some
fuzzy logic. Setting this up is well not a piece of cake at least for
me. I tried reading his patch and wasn't quite able to digest it in
the first read but then I didn't look into that further. I would
really like if someone could look this up and recommend whether I
should try and implement this or not in the first week. If let's say I
try to implement it, then I probably think it is more than a week's
job. I recollect Matthieu saying that Paul Tan had used this before.
Could you please explain how he achieved this?
When will I officially start working?
My end semester exams end on 29th April, 2016 and I will reach my home
on 1st May, 2016. I will officially start working from 2nd May, 2016
and will complete reading up on plumbing commands and other API parts
which seems a bit ambitious as for now.
Other remarks:
- I can now finally use git-send-email when I reach home.
- I will regularly (weekly) keep posting my progress on my blog[6]
which will be revived as it has been a bit stale for some time now. I
will also send the text-only version to the mailing list as requested
by Christian.
- The more I dived in, the more it started to realize that my time
line needs some restructuring which I guess can be determined by the
above paragraphs.
- I will also work out on a time line and post it on my blog[6] and
send it to mentors.
[1]: https://docs.google.com/document/d/1stnDPA5Hs3u0a8sqoWZicTFpCz1wHP9bkifcKY13Ocw/edit?usp=sharing
[2]: http://thread.gmane.org/gmane.comp.version-control.git/291311
[3]: http://thread.gmane.org/gmane.comp.version-control.git/289599
[4]: https://github.com/pranitbauva1997/git
[5]: http://thread.gmane.org/gmane.linux.kernel/2126762
[6]: http://bauva.in
next reply other threads:[~2016-04-23 20:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-23 20:10 Pranit Bauva [this message]
2016-04-24 6:52 ` GSoC Project Selected | Incremental Rewrite of git bisect Johannes Schindelin
2016-04-25 14:39 ` Matthieu Moy
2016-05-08 11:27 ` [GSOC update] Week 1 Pranit Bauva
2016-05-15 17:45 ` [GSOC Update] Week 2 Pranit Bauva
2016-05-15 18:01 ` Matthieu Moy
2016-05-15 19:17 ` Junio C Hamano
2016-05-15 19:11 ` Junio C Hamano
2016-05-15 19:30 ` Pranit Bauva
2016-05-22 19:58 ` [GSoC Update] Week 3 Pranit Bauva
2016-05-30 5:37 ` [GSOC Update] Week 2 Pranit Bauva
2016-05-30 5:45 ` Pranit Bauva
2016-06-06 6:53 ` [GSOC Update] Week 5 Pranit Bauva
2016-06-13 8:06 ` [GSOC Update] Week 6 Pranit Bauva
2016-06-20 7:37 ` [GSOC Update] Week 7 Pranit Bauva
2016-06-27 7:19 ` [GSOC Update] Week 8 Pranit Bauva
2016-07-03 20:27 ` [GSOC Update] Week 9 Pranit Bauva
2016-07-12 22:52 ` [GSOC Update] Week 10 Pranit Bauva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFZEwPMr=imv==kvVULy4PDYKW-0RRQ5a+X8DFqNFhNjCSyWKA@mail.gmail.com' \
--to=pranit.bauva@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=larsxschneider@gmail.com \
--cc=matthieu.moy@grenoble-inp.fr \
--cc=roberto.tyley@gmail.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).