On Fri, Feb 10, 2023 at 11:00 PM Vinayak Dev <vinayakdev.sci@xxxxxxxxx> wrote: > On Sat, 11 Feb 2023 at 03:31, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Vinayak Dev <vinayakdev.sci@xxxxxxxxx> writes: > > > Revert changes to alias.c, and change variable types in apply.c > > > > When you send out a rerolled series, you do not have to show your > > past mistakes. This [v2] is structured as a three patch series > > whose first one makes a similar mess as what [v1] did, the second > > one and the third one then revert some parts of that earlier mess. > > > > That is not what you want to show your reviewers, and more > > importantly, that is not what we want to record in our history. > > Rerolling a series is your chance to pretend that you are much > > better programmer than you who wrote the [v1] patch. The review > > exchange is to help you do that. Please take advantage of that. > > > > You may find "git rebase -i" is a useful tool to help you pretend > > that you got to the ideal end result without these "I tried this > > first, which was wrong in these points, which I correct in a > > subsequent step" steps. > > OK, I will keep that in mind before sending subsequent patches. > Should I re-send [v2] after making corrections for this mistake? > That would make the corrections more obvious and the mistakes less. You should send a v3 which completely replaces v1 and v2. To prepare v3, use the "squash" (or "fixup") command of `git rebase -i` to squash all three patches from v2 into a single patch, so that v3 consists of just one patch. The squashed patch should contain only changes to "apply.c"; specifically, changing #define to `enum`, and changing the variable declarations from `int` to `enum`. You can also update the commit message of the squashed patch so that it explains the reason for the patch: specifically, the debugger will display the values symbolically rather than as mere numbers. Finally, proofread the commit message and the patch itself, and resubmit as v3.
