On Fri, Feb 3, 2023 at 9:49 AM Kousik Sanagavarapu <five231003@xxxxxxxxx> wrote: > > Now, I think I understand the mistake that I did. Even if it did work > for one merge strategy, the code would not be good as the helper function > is not doing what it is intended to do. In any case, I should have been > more careful submitting the patch. > > On a side note, I think we can now close the issue #1156 on gitgitgadget? As > with builtin/merge.c out of the way, the only other case is in revision.c > and the use of the helper function there is inapproriate. > > Thanks for the explanation. Yeah, it should have been closed back when https://lore.kernel.org/git/CANsrJQd0v2V9H8HPkiH2179C1c-NOSTRRB8YXt8v6R0YAbFPDQ@xxxxxxxxxxxxxx/ was submitted. But none of us caught it. Also, gitgitgadget #1156 was opened because of my suggestion to do this as a "leftoverbit", i.e. I was suggesting it as a micro-project to new people. I should have checked at the time that it was a valid micro-project, but neglected to do so. You merely came along and started implementing what was suggested. Anyway, the point of the GSoC microprojects are to make sure you are familiar with how to format and submit patches to the mailing list and respond; having the code you contribute in a microproject be accepted is not required, just a bonus. And you clearly managed to send the patch to the list, had a correctly formatted commit message (short summary with area and correct lack of capitalization, good descriptions, signed-off-by), got the additional notes for reviewers (very helpful!) in the correct spot, etc., so I still see this as a successful microproject for you. I apologize for not doing my due diligence when I suggested it, and for us not catching that it should have been closed when someone implemented the valid half of the suggestion last year.
