X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=patchformatting.mdwn;h=73f7b10be4e12fe16c245ee020aacfd1ba7f1999;hb=7b82a05d8152381bdc5ea21a34a2c5487f1298f3;hp=cf5bf813c082337c0e3f2799b3f12f1588ef184a;hpb=889266d3dfcd3f478978cf136a94f3448696999a;p=notmuch-wiki

diff --git a/patchformatting.mdwn b/patchformatting.mdwn
index cf5bf81..73f7b10 100644
--- a/patchformatting.mdwn
+++ b/patchformatting.mdwn
@@ -25,13 +25,40 @@ working tree will follow.
 
 Enter your commit message in following format:
 
-      first commit line; one line description, up to 65 chars
+      first commit line; short one line description
       
       After one empty line, a detailed description of your changes
       the description most usually spans over multiple lines.
 
-The 65-character (limit) seems to be common among many projects so
-that is good guideline to follow here too.
+Wrap the lines to about __72__ characters or so. On an 80 column terminal,
+if we subtract 4 columns for the indent on the left and 4 more for
+symmetry on the right, we’re left with __72__ columns.
+
+Regarding the commit message body contents,
+Carl [has stated](http://article.gmane.org/gmane.mail.notmuch.general/504):
+
+> The single line summary is good about saying *what* the commit does,
+> but I always want to see at least one sentence about the *why* as well.
+
+### Activating default pre-commit hook
+
+Git provides a default pre-commit hook which, when activated, checks
+(at least) for whitespace errors (trailing whitespace and space before
+tab). It is better to notice this kind of "errors" early than have
+patch reviewers to mention about those.
+
+The hook, when activated, is named as .git/hooks/pre-commit and it
+has execute permissions set on. By default, when git tree is cloned
+your hooks dir may have default, inactive pre-commit hook available
+as:
+
+1. .git/hooks/pre-commit  without execute permission set
+
+2. .git/hooks/pre-commit.sample  usually with execute permission set
+
+In case of 2, enter `cp .git/hooks/pre-commit.sample .git/hooks/pre-commit`.
+And, now enter `chmod a+x .git/hooks/pre-commit` in case it does not
+have execute permission set.
 
 ## Remember: one patch per email
 
@@ -41,6 +68,16 @@ Eric S. Raymond has written good
 [Software Release Practice HOWTO](http://tldp.org/HOWTO/Software-Release-Practice-HOWTO/).
 Check what he has to say about this issue. 
 
+### Test Suite Enhancements
+
+New features as well as bug fixes should typically come with test suite
+enhancements.  The test suite changes should be done first (tagged as *expected
+to fail*), and the feature implementation or bug fix should come second
+(removing the *expected to fail* tag).  This way, the test suite specifies the
+behavior you're trying to implement, be it a new feature or a bug fix.  By
+defining beforehand exactly what you expect to happen, everyone can confirm
+that your patch achieves what it is meant it to.
+
 ## Prepare patches for e-mail submission
 
 If you've made just one commit (containing just one bugfix or new feature)
@@ -77,6 +114,38 @@ you can check with `git log` a 40-char commit-sha1 of the last commit
 every commit *after* that commit-sha1 will be used to generate 
 patch files...
 
+### Test-applying your patches
+
+Sometimes you may face a situation with your patches that you are unsure
+whether those patches apply to the origin. Such a cases might be:
+
+* You've taken your patches from a branch that has some other commits on top of origin.
+
+* You have edited the commit message, comments below commit message or the patch content itself in the patch files generated.
+
+To verify that your patches will apply on top of pristine origin you can 
+test-apply your patch files on origin/master:
+
+* Simple case -- no other changes on top of origin/master
+
+	git reset --hard origin/master
+        git pull
+	git am 00*
+
+* A case where working tree is dirty
+
+	git log -1 --format=%H > head_commit
+	git stash save
+	git reset --hard origin/master
+        git pull
+	git am 00*
+	
+	git reset --hard `cat head_commit`
+	git stash apply
+	rm head_commit
+	git stash drop
+	
+
 ## Sending patches
 
 ### Using git send-email