Stefan Beller <sbeller@xxxxxxxxxx> writes: > The disadvantage is that I need to have the high quality in a branch before > sending it out for review. But I personally find it easier to deal > with git branches > than with patch files of different versions. Branches do not forget > anything once > I edited it in which turns that point into an advantage for me. > ... > But how do I know if a patch is perfect? You said it yourself above, didn't you? While perfecting your branch and while perfecting reroll of your branch. >> Perhaps --add-header="x-reminder: what changed since the last?" >> would be sufficient for your purpose instead? > > I am not quite sure if that is my problem any more. Say I have the > following check list: > * Do I follow the coding style? > * indentation by tabs and spaces > * no superfluous braces > > * The code itself > * Does it embed into the current logic flow? > * memory leaks? > * Does it compile and test (git rebase --exec=make --exec="make test") ? > > * Is a patch small enough? > * Does it do one thing? (move code or add code, not both!) > > * Do I have a proper commit message? > * spelling and grammar > * Does the commit message (still) describe the changes of the patch? All of the above sounds like what you want to do once-per-patch, not once-per-series, so a reminder while reviewing each individual patch, not while writing the cover letter, would be a more appropriate place for them, no? > * After doing changes, wait at least 12 hours for second self-review This is certainly once-per-series. > * sending out: > git format-patch --cover-letter --notes --subject-prefix=PATCHvX This is not even helpful reminder if that is only shown after you run format-patch, no? > Most of it is on a per-patch basis, but it is easier to check for the whole > branch/series in one go after some time when you found some mental > distance to the code you wrote yourself. And for me this is usually > the next day, when I review it again and ask myself: Do I send out or not? > > As you can see there may be quite some discussion on what you want > to put into that check list, hence it should be configurable. We could of > course think about pre-populating the check list for new comers. Yes, but that is a separate discussion where the check list is given (per patch or per series?) and how it is presented (overriding the "blurb here" comment or something else that can also be used for the non-cover messages?). -- 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