Hey Junio, On Mon, May 16, 2016 at 12:41 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Pranit Bauva <pranit.bauva@xxxxxxxxx> 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. Okay. Will keep this in mind. >> * 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). Sure. >> * 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. Actually I was seeing how for-each-ref called filter_ref() and planning to use that. But for_each_ref_in() seems much better. Thanks. I had planned on using delete_ref(). > And reading the implementation of for-each-ref and update-ref is a > good way to find the need to use these API calls and how they are > used. API docs are your second step. Thanks. I have read the man pages as well as some parts of the implementation (not the core details). API docs contain little information about ref handling though. I can try trying writing some documentation after GSoC project once I am comfortable with ref handling. > Overall, good progress for an early week. Thanks! Regards, Pranit Bauva > Thanks. -- 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