git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [GSOC Update] Week 2

From
Junio C Hamano <gitster@pobox.com>
Date
May 15, 2016, 19:11 UTC
Message-ID
<xmqqoa875e7m.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<1463334359-14033-1-git-send-email-pranit.bauva@gmail.com>
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.

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.

Overall, good progress for an early week.
Thanks.
Previous: Junio C HamanoNext: Pranit Bauva
Message 8 of 18 in “GSoC Project Selected | Incremental Rewrite of git bisect”
  1. Pranit BauvaApr 23, 2016
  2. Johannes SchindelinApr 24, 2016
  3. Matthieu MoyApr 25, 2016
  4. [GSOC update] Week 1Pranit Bauva, May 8, 2016
  5. [GSOC Update] Week 2Pranit Bauva, May 15, 2016
  6. Matthieu MoyMay 15, 2016
  7. Junio C HamanoMay 15, 2016
  8. Junio C HamanoMay 15, 2016
  9. Pranit BauvaMay 15, 2016
  10. [GSoC Update] Week 3Pranit Bauva, May 22, 2016
  11. [GSOC Update] Week 2Pranit Bauva, May 30, 2016
  12. Pranit BauvaMay 30, 2016
  13. [GSOC Update] Week 5Pranit Bauva, Jun 6, 2016
  14. [GSOC Update] Week 6Pranit Bauva, Jun 13, 2016
  15. [GSOC Update] Week 7Pranit Bauva, Jun 20, 2016
  16. [GSOC Update] Week 8Pranit Bauva, Jun 27, 2016
  17. [GSOC Update] Week 9Pranit Bauva, Jul 3, 2016
  18. [GSOC Update] Week 10Pranit Bauva, Jul 12, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.