Re: [RFC PATCH] format-patch: Add config option format.coverbodytext to change the cover letter body

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> 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?).