Merge branch 'maint'
authorJunio C Hamano <gitster@pobox.com>
Tue, 25 May 2010 20:13:43 +0000 (13:13 -0700)
committerJunio C Hamano <gitster@pobox.com>
Tue, 25 May 2010 20:13:43 +0000 (13:13 -0700)
* maint:
Documentation/SubmittingPatches: clarify GMail section and SMTP
show-branch: use DEFAULT_ABBREV instead of 7
t7502-commit: fix spelling
test get_git_work_tree() return value for NULL

1  2 
Documentation/SubmittingPatches
index 8db22efbafc6d3881bc0551fd465cc135b456e9f,22e38086beb539cda221197663352b4deea76042..b9204c77d3b6070ec27b297cbd3e35d85f40e442
@@@ -41,6 -41,7 +41,7 @@@ Checklist (and a short version for the 
          maintainer (gitster@pobox.com) if (and only if) the patch
          is ready for inclusion. If you use git-send-email(1),
          please test it first by sending email to yourself.
+       - see below for instructions specific to your mailer
  
  Long version:
  
@@@ -53,34 -54,6 +54,34 @@@ But the patch submission requirements a
  here on the technical/contents front, because the core GIT is
  thousand times smaller ;-).  So here is only the relevant bits.
  
 +(0) Decide what to base your work on.
 +
 +In general, always base your work on the oldest branch that your
 +change is relevant to.
 +
 + - A bugfix should be based on 'maint' in general. If the bug is not
 +   present in 'maint', base it on 'master'. For a bug that's not yet
 +   in 'master', find the topic that introduces the regression, and
 +   base your work on the tip of the topic.
 +
 + - A new feature should be based on 'master' in general. If the new
 +   feature depends on a topic that is in 'pu', but not in 'master',
 +   base your work on the tip of that topic.
 +
 + - Corrections and enhancements to a topic not yet in 'master' should
 +   be based on the tip of that topic. If the topic has not been merged
 +   to 'next', it's alright to add a note to squash minor corrections
 +   into the series.
 +
 + - In the exceptional case that a new feature depends on several topics
 +   not in 'master', start working on 'next' or 'pu' privately and send
 +   out patches for discussion. Before the final merge, you may have to
 +   wait until some of the dependent topics graduate to 'master', and
 +   rebase your work.
 +
 +To find the tip of a topic branch, run "git log --first-parent
 +master..pu" and look for the merge commit. The second parent of this
 +commit is the tip of the topic branch.
  
  (1) Make separate commits for logically separate changes.
  
@@@ -198,16 -171,17 +199,16 @@@ patch, format it as "multipart/signed"
  that starts with '-----BEGIN PGP SIGNED MESSAGE-----'.  That is
  not a text/plain, it's something else.
  
 -Note that your maintainer does not necessarily read everything
 -on the git mailing list.  If your patch is for discussion first,
 -send it "To:" the mailing list, and optionally "cc:" him.  If it
 -is trivially correct or after the list reached a consensus, send
 -it "To:" the maintainer and optionally "cc:" the list for
 -inclusion.
 -
 -Also note that your maintainer does not actively involve himself in
 -maintaining what are in contrib/ hierarchy.  When you send fixes and
 -enhancements to them, do not forget to "cc: " the person who primarily
 -worked on that hierarchy in contrib/.
 +Unless your patch is a very trivial and an obviously correct one,
 +first send it with "To:" set to the mailing list, with "cc:" listing
 +people who are involved in the area you are touching (the output from
 +"git blame $path" and "git shortlog --no-merges $path" would help to
 +identify them), to solicit comments and reviews.  After the list
 +reached a consensus that it is a good idea to apply the patch, re-send
 +it with "To:" set to the maintainer and optionally "cc:" the list for
 +inclusion.  Do not forget to add trailers such as "Acked-by:",
 +"Reviewed-by:" and "Tested-by:" after your "Signed-off-by:" line as
 +necessary.
  
  
  (4) Sign your work
@@@ -546,9 -520,27 +547,27 @@@ Gmai
  
  GMail does not appear to have any way to turn off line wrapping in the web
  interface, so this will mangle any emails that you send.  You can however
- use any IMAP email client to connect to the google imap server, and forward
+ use "git send e-mail" and send your patches through the GMail SMTP server, or
+ use any IMAP email client to connect to the google IMAP server and forward
  the emails through that.
  
+ To use "git send-email" and send your patches through the GMail SMTP server,
+ edit ~/.gitconfig to specify your account settings:
+ [sendemail]
+       smtpencryption = tls
+       smtpserver = smtp.gmail.com
+       smtpuser = user@gmail.com
+       smtppass = p4ssw0rd
+       smtpserverport = 587
+ Once your commits are ready to be sent to the mailing list, run the
+ following commands:
+   $ git format-patch --cover-letter -M origin/master -o outgoing/
+   $ edit outgoing/0000-*
+   $ git send-email outgoing/*
  To submit using the IMAP interface, first, edit your ~/.gitconfig to specify your
  account settings:
  
@@@ -564,8 -556,7 +583,7 @@@ You might need to instead use: folder 
  that the "Folder doesn't exist".
  
  Once your commits are ready to be sent to the mailing list, run the
- following command to send the patch emails to your Gmail Drafts
- folder.
+ following commands:
  
    $ git format-patch --cover-letter -M --stdout origin/master | git imap-send
  
@@@ -573,19 -564,3 +591,3 @@@ Just make sure to disable line wrappin
  interface will line wrap no matter what, so you need to use a real
  IMAP client).
  
- Alternatively, you can use "git send-email" and send your patches
- through the GMail SMTP server.  edit ~/.gitconfig to specify your
- account settings:
- [sendemail]
-       smtpencryption = tls
-       smtpserver = smtp.gmail.com
-       smtpuser = user@gmail.com
-       smtppass = p4ssw0rd
-       smtpserverport = 587
- Once your commits are ready to be sent to the mailing list, run the
- following commands:
-   $ git format-patch --cover-letter -M origin/master -o outgoing/
-   $ git send-email outgoing/*