Re: [GSOC Update] Week 2

> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>>    is available for testing on the pu branch. I am encouraging people to
>>    test it and provide useful comments.
>
> Do not encourage people to "TEST".  In general, do not put too much
> weight on testing.  The result would only measure a small portion of
> what you wrote in the code, i.e. what you covered with the addition
> to the test suite, plus whatever tests we already had.
>
> Instead, ask people to review.  A new code passing the testsuite is
> a minimum requirement, and that is far from sufficient.

>>  * I have also converted bisect_log() and bisect_voc() whose patches[3] are
>>    sent to the list. Junio is yet to pick these up.
>
> Again, my picking them up is not a success criteria (and certainly
> being on 'pu' does not count for anything--it is nothing more than
> "Junio saw them on the list and bookmarked the messages".
>
> You should worry more about people not commenting nor reviewing them
> than me picking them up (which would typically come later).

>>  * The main part (I think) was that I read about the method's which handled the
>>    refs. It was an interesting read though I did not read upon the actual
>>    implementations of those, I mainly covered "What does the method do?" and
>>    "How to use the method in my code?". git-grep is my best friend for this.
>
> Yup.
>
> You would not be calling for-each-ref from a C rewrite of
> bisect-clean-state.  Instead you would likely be calling
> for_each_ref_in() to iterate over the existing refs/bisect/* refs,
> recording their refname and objectname from the callback to
> something like string_list, and then after for_each_ref_in()
> finishes, iterate over the resulting string_list and running
> delete_ref() on them.