Re: [PATCH] .github/PULL_REQUEST_TEMPLATE.md: add a note about single-commit PRs

> "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
>> index 952c7c3a2aa..65fa3a37173 100644
>> --- a/.github/PULL_REQUEST_TEMPLATE.md
>> +++ b/.github/PULL_REQUEST_TEMPLATE.md
>> @@ -4,4 +4,8 @@ a mailing list (git@vger.kernel.org) for code submissions, code reviews, and
>>  bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)
>>  to conveniently send your Pull Requests commits to our mailing list.
>>  
>> +If you use Gitgitgadget for a single-commit pull request, please *leave the pull
>> +request description empty*: your commit message itself should describe your
>> +changes.
>> +
>>  Please read the "guidelines for contributing" linked above!
> 
> Making it easier for contributors to come up with the right output
> is greatly appreciated.  I think "If you use Gitgitgadget for" ->
> "For" is probably a good change, for two reasons (one, we do not
> take pull request except for GGG gateway in the first place, and
> two, PR messages being similar to cover letters, you do not want to
> have a detailed PR message that (a) takes extra time to write, (b)
> can duplicate what the you already have written, and (c) could
> contradict what the commit log message says.

> I wonder if such a rule can be also enforced at the GGG side?  It
> apparently knows if it is dealing with a single-patch request or a
> multi-patch series (as the types of messages this documentation
> update tries to address are the only ones that get duplicates under
> the three-dash line), and I've seen GGG complain on the contents of
> the commit log message (e.g., "not signed off") so there is enough
> support to inspect things in a PR and add instruction to the PR
> discussion.  Unless the machinery GGG uses lack the ability to read
> the PR message (unlike the commit log messages that it can read
> apparently), it may be able to enforce that "for a single patch, PR
> message should be empty" rule before the /submit instruction.  It
> might make things even more helpful if it can notice the commit log
> message is similar enough or superset of PR message and refrain from
> inserting it after the three-dash line, but that might be asking too
> much ;-)