Re: [PATCH 2/2] Add submitGit patch-submission information

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 14, 2016, 22:27 UTC
Message-ID: <xmqq37qng721.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <0102015416d52b62-ce575cc4-6dc2-4097-8883-79baac701105-000000@eu-west-1.amazonses.com>

Roberto Tyley <roberto.tyley@gmail.com> writes:

Show 18 quoted lines

> +(3) Generate and send your patch to the Git mailing list
>  
>  People on the Git mailing list need to be able to read and
>  comment on the changes you are submitting.  It is important for
>  a developer to be able to "quote" your changes, using standard
>  e-mail tools, so that they may comment on specific portions of
>  your code.  For this reason, each patch should be submitted
> -"inline" in a separate message.
> +"inline" (not as an attachment) in a separate message.
> +
> +There can be unexpected problems in sending patches:
> +
> +  . Webmail clients like Gmail generally corrupt whitespace in patches.
> +  . messages using HTML-formatting (used by default in many webmail
> +    clients) is automatically rejected by the Git mailing list server.
> +
> +Because of these factors, it's recommended that you use one of these
> +specific methods to generate and send your patchs:

Perhaps:

    It's recommended ... your patches, unless you already know how
    to correctly send your patches as plain-text e-mails.

That is, the ones listed below are known to produce good patches, but our recommendation is _so_ strong to urge users with working set-up to migrate to them.

Show 10 quoted lines

> +
> +  - Generate mail-ready patch files using "git format-patch" and
> +    send them using "git send-email" to the Git mailing list.
> +    See SubmittingPatchesByMUA for further details.
>  
> +  - Create a pull request on https://github.com/git/git and
> +    use https://submitgit.herokuapp.com/ to send it as a patch series
> +    to the mailing list.  Note that the PR is just the place where your
> +    patch is born - discussion of the patch should still take place on
> +    the Git mailing list.

This is a tangent but I am wondering if you can do this _without_ creating a pull request to that repository. I have a watch on that repository and my notification gets unnecessarily large because of these pull requests that were made _only_ for submitGit. Can't submitGit be taught to take a branch in a repository of the submitter as input, (instead of a pull request to that public repository)?

Once it is done, you do not even have to say "Note that", as there is no room for confusion.

Show 24 quoted lines

> +Please make sure to review your patch before sending it, to ensure that
> +it:
>  
> +  . accurately reflects the change you want to make
> +  . does not add commented-out debugging code, or include any extra
> +    files which do not relate to what your patch is trying to achieve.
> +  . cleanly applies to the "master" branch head.  If you are preparing
> +    a work based on "next" branch, that is fine, but please mark it as
> +    such.
>  
>  It is a common convention to prefix your subject line with
>  [PATCH].  This lets people easily distinguish patches from other
> @@ -186,7 +200,7 @@ patch.
>       *2* The mailing list: git@vger.kernel.org
>  
>  
> -(5) Sign your work
> +(4) Sign your work
>  
>  To improve tracking of who did what, we've borrowed the
>  "sign-off" procedure from the Linux kernel project on patches
>
> --
> https://github.com/git/git/pull/223