On Sun, May 8, 2016 at 9:34 AM, Pranit Bauva <pranit.bauva@xxxxxxxxx> wrote: > On Sun, May 8, 2016 at 11:53 AM, Pranit Bauva <pranit.bauva@xxxxxxxxx> wrote: >> On Sun, May 8, 2016 at 7:55 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Pranit Bauva <pranit.bauva@xxxxxxxxx> writes: >>>> I completely missed your point and you want me to go the Eric Sunshine's way? >>> >>> I am neutral. >>> >>> When I read your response to Eric's "top down" suggestion, I didn't >>> quite get much more than "I started going this way, and I do not >>> want to change to the other direction.", which was what I had the >>> most trouble with. If your justification for the approach to start >>> from building a tiny bottom layer that will need to be dismantled >>> soon and repeat that (which sounds somewhat wasteful) were more >>> convincing, I may have felt differently. >> >> Sorry if it seemed that "I have done quite some work and I don't want >> to scrape it off and redo everything". This isn't a case for me. I >> think of this as just a small part in the process of learning and my >> efforts would be completely wasted as I can still reuse the methods I > > efforts would **not** be completely wasted > >> wrote. This is still open for a "philosophical" discussion. I am >> assuming 1e1ea69fa4e is how Eric is suggesting. Speaking of 1e1ea69 (pull: implement skeletal builtin pull, 2015-06-14), one of the (numerous) things Paul Tan did which impressed me was to formally measure test suite coverage of the commands he was converting to C, and then improve coverage where it was lacking. That approach increases confidence in the conversion far more than fallible human reviews do. Setting aside the top-down vs. bottom-up discussion, as a reviewer (and user) I'd be far more interested in seeing you spend a good initial chunk of your project emulating Paul's approach to measuring and improving test coverage (though I don't know how your GSoC mentors feel about that). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html