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

From: Junio C Hamano <[email-masked]>
Date: Sun, 04 Feb 2024 12:17:39 -0800

"Philippe Blain via GitGitGadget" <[email-masked]> 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 ([email-masked]) 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 ;-)

Thanks for helping to improve the situation.

Will queue.