emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git-send-email (was: Why are so many great packages not trying to ge


From: Eli Zaretskii
Subject: Re: git-send-email (was: Why are so many great packages not trying to get included in GNU Emacs?)
Date: Mon, 15 Jun 2020 05:37:12 +0300

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  alan@idiocy.org,  hi-angel@yandex.ru,
>   stefan@marxist.se,  emacs-devel@gnu.org
> Date: Mon, 15 Jun 2020 00:11:38 +0200
> 
> As Konstantin said, the patch[1] was sent with git send-email, which
> allows the sender to "annotate" the patch with some text that will be
> ignored by git am (IIUC merely by virtue of being stuck between "---\n"
> and the actual diff).
> 
> In Gnus, piping the whole mail to "cd path/to/emacs && git am" (hitting
> "|" in the summary buffer) mostly does TRT: the patch is applied, with
> the email's subject as commit summary, and the rest of the message (up
> to "---\n") completing the commit message.
> 
> The only issue, AFAICT, is that git am fails to strip away the [PATCH]
> prefix; IUUC this is because it does not expect debbugs's own "bug#NNN"
> prefix.
> 
> 
> Feel free to dismiss this as armchair commentary, but I think that we're
> likely to see more and more patches sent with git send-email[2], since
> it is heavily promoted by other projects privileging mail-based
> workflows[3].

We accept and welcome patches in any form and shape.  However, we
recommend to use "git format-patch" (see CONTRIBUTE), and for a good
reason: doing so leaves no doubt regarding the authorship of the
changes.  Whereas just sending email could dupe us in attributing the
change to a different person, something that we try to avoid.  Of
course, with enough manual work and using various Git optional
switches, any problem can be worked around, for the price of more time
invested.

This is why I generally comment on patches sent in forms other than
what is described in CONTRIBUTE.  Eventually, that is our main
contribution document, and we should either stick to what it says or
change the document.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]