From: Matthieu Moy <Matthieu.Moy@grenoble-inp•fr>
To: Pranit Bauva <pranit.bauva@gmail•com>
Cc: Christian Couder <christian.couder@gmail•com>,
Git List <git@vger•kernel.org>,
Johannes Schindelin <johannes.schindelin@gmx•de>,
Stefan Beller <sbeller@google•com>,
Lars Schneider <larsxschneider@gmail•com>,
Jeff King <peff@peff•net>, Troy Moure <troy.moure@gmail•com>,
Junio C Hamano <gitster@pobox•com>,
Eric Sunshine <sunshine@sunshineco•com>,
Kevin Daudt <me@ikke•info>, Philip Oakley <philipoakley@iee•org>
Subject: Re: GSoC Project | Improvise git bisect
Date: Sun, 20 Mar 2016 14:24:40 +0100 [thread overview]
Message-ID: <vpq4mc1e0yv.fsf@anie.imag.fr> (raw)
In-Reply-To: <CAFZEwPP2OLOQanazPXxK1u5GVHzFWqx8GuRad7tLUyHrWR_+Tw@mail.gmail.com> (Pranit Bauva's message of "Sun, 20 Mar 2016 17:05:21 +0530")
Pranit Bauva <pranit.bauva@gmail•com> writes:
> The project Idea: Incremental Rewrite from shell to C of git-bisect.sh
>
> The plan:
>
> - Place bisect.c in builtin/
> - Implement a skeletal cmd_bisect() which will redirect to
> git-bisect.sh (1e1ea69f)
> - Introduce a structure for parsing the command line flags.
> - Start converting individual functions and place it in bisect.c
The most important question is missing from this: how do you ensure that
you periodically fall back to a consistant state (i.e. a state where
your code is used and the whole testsuite passes)?
Without this, the timeline may look like:
- day 1: the 3 first steps above
- 2 months: convert individual functions
- last day: submit the whole thing
And you absolutely want to avoid this. You need to get reviewable and
mergeable code ASAP.
As I wrote earlier, I'm not convinced that your plan is the best
approach. Converting shell functions to the bisect helper is IMHO a
better first step, and having a builtin cmd_bisect can come later.
> a list of commits and then store the standard output in an array as
> bash can directly do the conversion, but it would not be a good thing
> to do in C.
Small confusion here: there's no bash involved, just a POSIX /bin/sh
(which may, or may not point to bash), and POSIX /bin/sh has no notion
of array.
> The goal would be to produce quality code that can be included in the
> next maintenance release 2.7.5.
I don't think this is a candidate for a maintenance release. Maintenance
release include fixes for which we're confident enough that no
regression or unexpected behavior change will happen. Complete rewrite
is the opposite of that.
> Also I am quite unsure how
> the patches would be maintained by Junio. Would he create a separate
> branch for me in his personal repo and then add the patches to it
> without merging it to pu and then when it is completely done, the
> merge will take place? Or he will individually first place every patch
> in pu and the normal process?
Junio usually does not maintain branches that are not merged in pu.
"merged in pu" does not mean "accepted", just "worth paying attention".
But this implies "does not introduce obvious regression" (cf. above).
Each series is applied in its own branch, and then this branch is merged
into pu.
We consider GSoC students as normal contributors when it comes to
submitting code (that's one of the reason why Junio is not a mentor).
> Should I also include "How git bisect works internally?" in the
> proposal along with this?
You should include any convincing argument to support the claim that you
are able to comptlete the project. I think this includes re-explaining
in your own words how you understand bisect in its current form.
> And most importantly, Would anyone like to mentor me for this project?
Christian is a potential mentor and he knows bisect very well. I can't
speak for him, but he'd probably be a good mentor for such project.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2016-03-20 13:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-19 9:33 GSoC Project | Improvise git bisect Pranit Bauva
2016-03-19 12:48 ` Matthieu Moy
2016-03-19 16:14 ` Christian Couder
2016-03-19 16:49 ` Pranit Bauva
2016-03-19 22:05 ` Stefan Beller
2016-03-20 8:10 ` Pranit Bauva
2016-03-20 11:35 ` Pranit Bauva
2016-03-20 13:24 ` Matthieu Moy [this message]
2016-03-20 13:25 ` Christian Couder
2016-03-20 15:31 ` Johannes Schindelin
2016-03-20 16:26 ` Pranit Bauva
2016-03-20 18:08 ` Matthieu Moy
2016-03-21 7:18 ` Johannes Schindelin
2016-03-21 7:29 ` Pranit Bauva
2016-03-21 17:53 ` Christian Couder
2016-03-21 18:13 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpq4mc1e0yv.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp$(echo .)fr \
--cc=christian.couder@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=johannes.schindelin@gmx$(echo .)de \
--cc=larsxschneider@gmail$(echo .)com \
--cc=me@ikke$(echo .)info \
--cc=peff@peff$(echo .)net \
--cc=philipoakley@iee$(echo .)org \
--cc=pranit.bauva@gmail$(echo .)com \
--cc=sbeller@google$(echo .)com \
--cc=sunshine@sunshineco$(echo .)com \
--cc=troy.moure@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox