[PATCH/RFC] Add some tips for contributors.
--- [Side note: Committing people's patches edited is a no no. At least I strongly prefer having a discussion and resending the patch, possibly several times, to having my patch edited (and possibly borken, which seems to have happened with 9b9c0298530) and committed under my name. Or being asked "I'll commit this instead/squash these changes in, OK?".] .gitattributes | 1 + CONTRIBUTE | 32 ++++++++++++++++++++++++++++++++ Header | 3 ++- 3 files changed, 35 insertions(+), 1 deletions(-) create mode 100644 .gitattributes create mode 100644 CONTRIBUTE diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..b362cfa --- /dev/null +++ b/.gitattributes @@ -0,0 +1 @@ +*.el diff=lisp diff --git a/CONTRIBUTE b/CONTRIBUTE new file mode 100644 index 0000000..70988e4 --- /dev/null +++ b/CONTRIBUTE @@ -0,0 +1,32 @@ +So you want to contribute? That's great, thank you! Here are some tips that +will help you make us cry with delight at the very sight of your patch: + +Patch format +------------ +- it's best if the patches are directly processable by Git (such as when using + `git-format-patch', `git-send-email' or the ---8<--- scissors trick) +- a nice way to have Git produce better diff hunk headers when working with + Lisp code is to add this to your config: + +[diff "lisp"] + xfuncname = "^\\(.*$" + +With this and an appropriate diff attribute definition (provided by the +.gitattributes file in the repository), it will be immediately visible which +top level Lisp form a particular hunk pertains to. + +Commit messages +--------------- +- the first line is a commit summary, usually a single sentence in imperative + (starting with a capital letter and ending with a period) short enough to fit + in a mail subject line +- after that and a blank line comes the commit message with a free form + explanation (optional for trivial patches) + +General coding guidelines +------------------------- +- keep it inside 80 columns when possible +- avoid trailing whitespace (Git can help you with that) +- if you're making bigger changes, it's a good idea to try byte-compiling + Vimpulse even though you normally don't (the compiler sometimes catches + issues not obvious when running uncompiled) diff --git a/Header b/Header index 99661ce..1b07281 100644 --- a/Header +++ b/Header @@ -41,5 +41,6 @@ ;; ;; Vimpulse is under active development. It works quite well with ;; GNU Emacs 22.3 and 23.2, as well as XEmacs 21.4.22. Patches and -;; feature requests are welcome. +;; feature requests are welcome (see also the file CONTRIBUTE in the +;; repository). -- 1.7.1
On 2010-07-23 13:27, Štěpán Němec wrote:
Committing people's patches edited is a no no. At least I strongly prefer having a discussion and resending the patch, possibly several times, to having my patch edited (and possibly borken, which seems to have happened with 9b9c0298530) and committed under my name. Or being asked "I'll commit this instead/squash these changes in, OK?".
Sure. (But how is commit [9b9c0298530] "borken"? All I did was to reformat the comment + add a period to the commit summary.) -- Vegard
Vegard Øye <[email protected]> writes:
On 2010-07-23 13:27, Štěpán Němec wrote:
Committing people's patches edited is a no no. At least I strongly prefer having a discussion and resending the patch, possibly several times, to having my patch edited (and possibly borken, which seems to have happened with 9b9c0298530) and committed under my name. Or being asked "I'll commit this instead/squash these changes in, OK?".
Sure.
(But how is commit [9b9c0298530] "borken"? All I did was to reformat the comment + add a period to the commit summary.)
What I see in `git log' output for that commit is a single huge line instead of the normally formatted paragraph I see in Tim's message (and no blank line between summary and the message proper). Štěpán
On 2010-07-23 14:20, Štěpán Němec wrote:
What I see in `git log' output for that commit is a single huge line instead of the normally formatted paragraph I see in Tim's message (and no blank line between summary and the message proper).
Oops. :-/ One could use git rebase to rectify such mistakes. Unfortunately, Assembla's server has receive.denyNonFastForwards set to true, preventing rewriting of history. Changing such settings is not available to free members. -- Vegard
Vegard Øye <[email protected]> writes:
On 2010-07-23 14:20, Štěpán Němec wrote:
What I see in `git log' output for that commit is a single huge line instead of the normally formatted paragraph I see in Tim's message (and no blank line between summary and the message proper).
Oops. :-/
One could use git rebase to rectify such mistakes. Unfortunately, Assembla's server has receive.denyNonFastForwards set to true, preventing rewriting of history. Changing such settings is not available to free members.
Well, you really should never rewrite history of a public repository anyway. What you certainly _should_ do is double-check the local commits before you push them to the repo. ;-) Štěpán
On Fri, Jul 23, 2010 at 7:00 AM, Štěpán Němec <[email protected]> wrote:
Vegard Øye <[email protected]> writes:
On 2010-07-23 14:20, Štěpán Němec wrote:
What I see in `git log' output for that commit is a single huge line instead of the normally formatted paragraph I see in Tim's message (and no blank line between summary and the message proper).
Oops. :-/
One could use git rebase to rectify such mistakes. Unfortunately, Assembla's server has receive.denyNonFastForwards set to true, preventing rewriting of history. Changing such settings is not available to free members.
Well, you really should never rewrite history of a public repository anyway. What you certainly _should_ do is double-check the local commits before you push them to the repo. ;-)
Štěpán
Vegard, I'm curious, how did you go about applying my patch? I've never seen `git am` do that to e-mail patches before
okay, I sent those patches via "git-send-email". You can take the raw email text and pipe it through `git am`, and it will apply it right :) Thank you for accepting my patches! In the future, would you prefer that I attach the patches as attachments rather than use git-send-email to send email patches? Tim On Fri, Jul 23, 2010 at 11:14 AM, Vegard Øye <[email protected]> wrote:
On 2010-07-23 18:15, Tim Harper wrote:
Vegard, I'm curious, how did you go about applying my patch? I've never seen `git am` do that to e-mail patches before
It didn't -- I amended the commit after applying the patch.
-- Vegard
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On Fri, Jul 23, 2010 at 12:35 PM, Tim Harper <[email protected]> wrote:
okay, I sent those patches via "git-send-email". You can take the raw email text and pipe it through `git am`, and it will apply it right :)
Thank you for accepting my patches! In the future, would you prefer that I attach the patches as attachments rather than use git-send-email to send email patches?
Tim
Or, if you have an email client that allows you to save messages to the disk, you can run git am <my-email-patch.msg> Tim
On 2010-07-23 20:35, Tim Harper wrote:
Thank you for accepting my patches! In the future, would you prefer that I attach the patches as attachments rather than use git-send-email to send email patches?
Either is fine. When inline, I just save the message with Thunderbird and pass the resulting .eml file to git am. -- Vegard
participants (3)
-
Tim Harper -
Vegard Øye -
Štěpán Němec